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

[Alexander Adolf <alexander.adolf@condition-alpha.com>]

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

> [...]
> A "completion table" can take several shapes, one of which is
> a function.
> [...]

That clarifies, thanks. We're on the same page.

Now I _think_ I understood a little better where you seem to be heading.
It appears your (as of yet not explicitly described) goal is to have a
collection of message--name-table type things in message.el, and
depending on the completion context plug the corresponding one of them
into at (list beg end collection) construct, which is then returned by
message-completion-function?

One of the added values of message--name-table seems to be the
marshalling of, and the merging of results from, the different
completion sources (eudc, bbdb, and ecomplete; not mailabbrev though?).

EUDC has recently gained the ability to do multi-server queries, and
deliver the combined results from all servers, and it was hence my idea
that this marshalling/merging functionality could now conveniently be
outsourced from message.el to EUDC. There is a bbdb back-end for EUDC
already, and I have back-ends for ecomplete and mailabbrev sitting on my
hard drive. I.e. there would not be any "degradation" in terms of
end-user functionality (same set of completion candidates as before),
and additional sources like e.g. LDAP, and macOS Contacts would become
available "for free" by calling eudc-query-with-words with its new
TRY-ALL-SERVERS parameter set to t.

It would seem that quite a couple of lines of code could be "commented
out" of message.el under `(if (<= emacs-major-version 29) ...)` as a
result of such a change.

Also, message.el would no longer need to deal with any completion UI
issues, and any completion UI related code in ecomplete, and mailabbrev
would no longer be used.

Another thing to look at would seem the "harvesting" of email addresses.
Today, there is support for ecomplete in message.el. It might be just as
(more?) appropriate to provide a new hook for this? Along the lines of
what is now in message-put-addresses-in-ecomplete, instead of a
hard-coded call to ecomplete, user-provided hook functions could be
called for each header.

At the end of the day, message.el would be completely independent of
what databases people use, or don't use. It would interface with EUDC
only, and leave "address harvesting" to user functions called from a new
message send hook.


Many thanks and looking forward to your thoughts,

  --alexander