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

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

>    ┌────
>    │ (defcustom message-completion-alist
>    │   `((,message-newgroups-header-regexp
>    │      . '(:capf-style 'newsgroup
>    │          :capf-funs  '(gnus-capf-complete)))    ;; hypothetical
>    │     (,message-email-recipient-header-regexp
>    │       . '(:capf-style 'email
>    │           :capf-funs  '(eudc-capf-complete))))  ;; exists
>    │   "docstring"
>    │   )
>    └────

Sounds fine, tho "capf-style" sounds wrong: these are the names of
categories, not a styles.

Also `capf-funs` sounds wrong: these should be completion tables
not CAPFs.  The CAPFs are the functions which decide which completion
table to use and what's the BEG...END that's being completed, and this
should not depend on the backend since they only depend on the format of
messages (and hence belong in `message.el`).

Currently we have `message-completion-alist` which decides on
a line-by-line basis what kind of completion we're doing, and then we
have a specialized function that decides what's the BEG..END to use and
which backend to use.

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

Maybe have it be a list of (FUNCTION CATEGORY . BACKENDS) ?
where FUNCTION should return (BEG . END) if this completion applies?

> 2) Refactor ecomplete, mailabbrev, and bbdb stuff out of message.el as
>    much as possible.

AFAIK this is already done for `ecomplete`.


        Stefan