> > 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.
>