Re: Completion functions in message-mode

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> message-mode adds message-expand-group and message-tab-body-function to
>> `completion-at-point-functions'. Both of these functions check if
>> they're in an appropriate location, and bail if not, allowing other
>> functions to do their thing.
>
> I think it's OK for Gnus to keep using message-completion-alist, but
> message-expand-name should use a completion table which can be extended,
> so EUDC, BBDB, ecomplete, and YouNameIt can add themselves to it.
>
>> Packages such as EUDC and BBDB put their own functions in
>> `completion-at-point-functions' (in the message-mode hook).
>
> That doesn't sound right: the code which decides if we're inside
> a message header, and which header contains email addresses, and how
> they're separated (i.e. the code which knows about the format of
> messages) should squarely belong to message-mode and not to
> BBDB/EUDC/...
>
> Instead these backends should only provide completion tables that
> provide user names, email addresses, or such data.
>
> I.e. the completion-at-point-function should come from message.el and
> the completion-tables it returns should come from BBDB/EUDC/...

Good! Thanks, that's the direction I needed.

My next question is, how does one "extend" a completion table?
Specifically: if c-a-p expects to receive (START END COLLECTION), should
the message-mode capf function marshal collections from various
backends, and offer them up as part of that one return value?

So say we add a message-name-completion-functions option, each backend
adds its function there, and message-mode calls all those functions,
gathers the results, and returns them to `completion-at-point'?

Almost there,
Eric