Re: Abbrev suggestions - feedback appreciated

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> [ Note: your patch seems to have its TABs converted into SPCs, messing
>>   up indentation.  I tried to fix those when quoting your code, but
>>   I may have mishandled some parts.  ]
> I'll have a look at that at my next attempt.  Are you saying there should be
> TABs in Emacs' .el files?

No: neither that it should nor that it shouldn't.  Just that indentation
was weird and the reason was probably that some TABs were mishandled by
the mail transport.

> Looking at the other defcustoms in the same file, probably not. I guess I
> added that when I first wrote absug.el, thinking it was a convenience
> thing. To be honest I think abbrevs are a convenience thing,

I think we all agree: the `abbrev-mode` group is inside the `abbrev`
group which is inside the `convenience` group ;-)

Maybe this could be restructured to make it less deep, but I'm not the
right person to talk to for that.

>> What would be the disadvantages/risks of enabling it by default?
> Of the top of my head, some people might be annoyed by the constant
> "nagging" about using abbrevs.

Could be, but I suspect those people who'd be annoyed don't have any
abbrevs to start with, so abbrev suggestions won't annoy them ;-)

> They could of course turn it off, if we enable it by default.

Yes, I'm tempted to enable it by default.  But indeed it's important
that it can be disabled easily (and maybe we'll end up disabling by
default).

> The first does not have a group set and the second has convenience as group
> as well.  I have never thought about if this is a normal or not. Is it?

I think the `:group` args there should be removed, indeed.

> That is mentioned in other places too, that it should return what was
> inserted, if any. It did not feel right to mess with that, but perhaps it
> is okay... Here is an attempt:
>
> (defun expand-abbrev ()
>   "Expand the abbrev before point, if there is an abbrev there.
> Effective when explicitly called even when `abbrev-mode' is nil.
> Before doing anything else, runs `pre-abbrev-expand-hook'.
> Calls the value of `abbrev-expand-function' with no argument to do
> the work, and returns whatever it does.  (That return value should
> be the abbrev symbol if expansion occurred, else nil.)"
>   (interactive)
>   (run-hooks 'pre-abbrev-expand-hook)
>   (or (funcall abbrev-expand-function)
>       (abbrev-suggest-maybe-suggest)))
>
> Is something like that what you had in mind?

That seems good, yes.  Tho please make sure
`abbrev-suggest-maybe-suggest` returns nil, or use

   (or (funcall abbrev-expand-function)
       (progn
         (abbrev-suggest-maybe-suggest)
         nil))

>> I think you'd be better served defining a dolist-style macro or
>> a mapc-style function to loop over all abbrevs without creating an
>> intermediate list.
> Sorry, I don't understand what you are suggesting, and why (performance, or
> saving memory?).

The idea is to avoid the memory allocation, yes.  It should improve
performance and reduce the frequency of GC pauses.

>> > +(defun abbrev--suggest-count-words (expansion)
>> Why does your code pay attention to words?
> I'll think about that... Are you thinking that only characters matter?

No, it's just that currently Abbrevs don't treat words specially, and
some uses of abbrevs can expand to things that aren't just made of words.

> I think my focus is primarily using abbrevs for sentences.

Right, but abbrevs are also used in programming languages and other
"non-prose" contexts.  So, it's better if we can make it work without
assuming "words".

> I'll try to cook a new version now.

Looking forward to it,


        Stefan