Re: Thoughts on Refactoring In-Buffer Completion In message.el

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

>> Sounds fine, tho "capf-style" sounds wrong: these are the names of
>> categories, not a styles.
> These names were just for illustration, so happy to use better fitting
> names.
> Perhaps `completion-style-category`? A shorter version?

It's not a "style category": it's more a "completion category" (it's not
a classification of styles but a classification of completion candidates).
To any given category the user can then associate some styles (as well
as control the cycling behavior).

>> Also `capf-funs` sounds wrong: [...]
> They are either tables, or functions that return tables.

I think they should be only completion tables (and most/all of those
tables will be functions: completion tables can take the shape of lists
of strings, alists, hash-tables, obarrays, or functions, but the only
think we care about is that they work with the corresponding methods).

That part that's wrong is not "funs" but "capf", because "capf" refers
to `completion-at-point-functions` which are not completion tables but
functions that return (BEG END TABLE).  They're related but
they're different.

>> Maybe `message-completion-alist` should be beefed up so that it cuts
>> this middle man (specialized function): i.e. provide not just
>> a line-based regexp to decide which specialized function to use, but
>> also provide some way to specify the BEG..END and the backend*S*.
> Good point, and agreed that determining (beg . end) should also be done
> in message.Eli.

Nice typo, thank you.  Indeed, maybe in order to mark the enormous
contribution of Eli to Emacs, maybe ELisp source files should end in
`.Eli` ;-)

>> Maybe have it be a list of (FUNCTION CATEGORY . BACKENDS) ?
>> where FUNCTION should return (BEG . END) if this completion applies?
> In some situations this will be called for every keystroke. Would the
> extra overhead of a function call seem acceptable for this?

An extra function call will be completely lost in the noise, yes.

> OTOH, the code of each of those functions would probably look extremely
> similar. The format of header lines where specific completion is to be
> attempted always seems to be:
>
>     header-label ':' record | record-list
>
> (I'm thinking of To/Cc/etc. and Newsgroups/Followup-To/etc.)
>
> Thus, the only parameters for such functions would seem to be a regular
> expression to match the header-label, and the character (or regex?) that
> is used as the record separator. So we might just as well put the
> header-label regex, and the record separator char in
> `message-completion-alist`?

You might be right, maybe we just need to add a record separator.

> 1390:The default is `abbrev', which uses mailabbrev.  `ecomplete' uses
> 1396:		 (const :tag "Use ecomplete" ecomplete)
> 1400:  "List of `self-insert-command's used to trigger ecomplete.
> 1402:header, ecomplete will suggest the candidates of recipients (see also
> 1937:(defvar message-inhibit-ecomplete nil)

These non-executable.

> 3097:  (when (and (message-mail-alias-type-p 'ecomplete)
> 3181:   ((message-mail-alias-type-p 'ecomplete)
> 3182:    (ecomplete-setup)))
> 4445:      ;; Do ecomplete address snarfing.
> 4446:      (when (and (message-mail-alias-type-p 'ecomplete)
> 4447:		 (not message-inhibit-ecomplete))
> 4448:	(message-put-addresses-in-ecomplete))
> 8021:	    (message-inhibit-ecomplete t)
> 8344:`ecomplete', `message-self-insert-commands' should probably be
> 8414:	   (ecomplete-setup)
> 8420:	                (when (and (bound-and-true-p ecomplete-database)
> 8421:	                           (fboundp 'ecomplete-completion-table))
> 8423:                                           (ecomplete-completion-table 'mail)
> 8628:(declare-function ecomplete-add-item "ecomplete" (type key text))
> 8629:(declare-function ecomplete-save "ecomplete" ())
> 8631:(defun message-put-addresses-in-ecomplete ()
> 8632:  (require 'ecomplete)
> 8640:	(ecomplete-add-item 'mail (car (mail-header-parse-address string))
> 8642:  (ecomplete-save))
> 8644:(autoload 'ecomplete-display-matches "ecomplete")
> 8666:		    (ecomplete-display-matches 'mail word choose))))
> 8671:(defun message-ecomplete-capf ()
> 8674:  (when (and (bound-and-true-p ecomplete-database)
> 8675:             (fboundp 'ecomplete-completion-table)
> 8683:      `(,start ,end ,(ecomplete-completion-table 'mail)))))
>
> That's 40 hits, and looking at the matching lines, my first impression
> would not frankly be that ecomplete integration has been reduced to a
> bare minimum.

Maybe I didn't express myself clearly enough: I meant that the
ecomplete-based *completion* code has been clearly separated.
It basically only uses `ecomplete-completion-table`.

`message-ecomplete-capf` was my first attempt at doing it cleanly: it
was clean alright, but it didn't allow combing this backend with
another one.  It's not used any more but is kept in case someone else
still uses it.  The place where `ecomplete` completion is used nowadays
is `message--name-table` which is supposed to combine EUDC, BBDB, and
Ecomplete completion tables into a single completion table.


        Stefan