|Subject:||Re: [PATCH] Add abbrev suggestions|
|Date:||Tue, 15 Sep 2020 00:04:05 +0200|
> > 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
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.
/MathiasOn Thu, Aug 13, 2020 at 3:59 PM Eli Zaretskii <firstname.lastname@example.org> wrote:> From: Mathias Dahl <email@example.com>
> Date: Wed, 12 Aug 2020 00:16:33 +0200
> Cc: firstname.lastname@example.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"
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
> Should I include those changes in the same patch and resend
> that when done?
Description: Binary data
|[Prev in Thread]||Current Thread||[Next in Thread]|