Re: [PATCH] Add abbrev suggestions

[Mathias Dahl]

> > No, I'm not. In fact, it was not the default when I started
> > working on this, but Stefan suggested that it might be a good
> > default. Now we're me and you against him, I guess... :)

> Let's start with having it opt-in.  We can later see if it is
> popular enough to become the default.

Fine by me.

> How about the below?

> Return non-nil if an abbrev in EXPANSION provides significant
> savings.

Hey, that's cheating! :)

I prepared a new version myself too. Will see which one I select when
I send a new patch...

> > Should I include those changes in the same patch and resend
> > that when done?

> Yes, please.

Alrighty then!

Thanks!

/Mathias

On Thu, Aug 13, 2020 at 3:59 PM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Mathias Dahl <mathias.dahl@gmail.com>
> Date: Wed, 12 Aug 2020 00:16:33 +0200
> Cc: emacs-devel@gnu.org
>
> > Are you sure it is a good idea to make this non-nil by default?
> > Wouldn't some users consider these suggestions an annoyance?
>
> No, I'm not. In fact, it was not the default when I started working on
> this, but Stefan suggested that it might be a good default. Now we're
> me and you against him, I guess... :)

Let's start with having it opt-in.  We can later see if it is popular
enough to become the default.

> > > +(defun abbrev--suggest-above-threshold (expansion)
> > > +    "Return t if we are above the threshold.
> >
> > Who is "we" in this context?  This should be explained.
>
> I know, I was not happy when I wrote that. "we", here, is something
> like "the difference in length between what the user typed and the
> abbrev that we found." I guess I could not find a good way to keep the
> first sentence of the docstring short, so I opted for the fuzzy "we"
> _expression_...

How about the below?

  Return non-nil if an abbrev in EXPANSION provides significant savings.

> > > +EXPANSION is a cons cell where the car is the expansion and the
> > > +cdr is the abbrev."
> >
> > Our style is to include the arguments in the first sentence of the doc
> > string.
>
> I know. Frankly I don't know if I can come up with a suggestion that
> combines that together with having a relatively short first
> sentence...

See above.

> Should I include those changes in the same patch and resend
> that when done?

Yes, please.