Re: master 620ac67355: EUDC: Add completion-at-point support

Re: master 620ac67355: EUDC: Add completion-at-point support

[Stefan Monnier]

> +;;    The first mechanism is intended for use by the modes listed in
> +;;    `eudc-capf-modes', and relies on these modes adding
> +;;    `eudc-capf-complete' to `completion-at-point-functions', as
> +;;    would be usually done for any general-purpose completion
> +;;    function.  In this mode of operation, and in order to offer
> +;;    email addresses only in contexts where the user would expect
> +;;    them, a check is performed whether point is on a line that is a
> +;;    message header field suitable for email addresses, such as for
> +;;    example "To:", "Cc:", etc.
> +;;
> +;;    The second mechanism is intended for when the user modifies
> +;;    `message-completion-alist' to replace `message-expand-name' with
> +;;    the function `eudc-capf-message-expand-name'.  As a result,
> +;;    minibuffer completion (`completing-read') for email addresses
> +;;    would no longer enabled in `message-mode', but
> +;;    `completion-at-point' (in-buffer completion) only.

Could you contrast the behavior of this new code with the one we get
from `message--name-table` (i.e. when setting
`message-expand-name-standard-ui`)?

Looking at the code in message.el it seems it should provide a fairly
similar behavior.  It seems to do similar caching, uses
(eudc-query-with-words (split-string orig-string "[ \t]+")) like your
code, tho your code passes an extra t arg to "try-all-servers".
Maybe message.el should also use that?

Any other difference?


        Stefan

Re: master 620ac67355: EUDC: Add completion-at-point support

[Alexander Adolf]

Hello Stefan,

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

> [...]
> Could you contrast the behavior of this new code with the one we get
> from `message--name-table` (i.e. when setting
> `message-expand-name-standard-ui`)?
>
> Looking at the code in message.el it seems it should provide a fairly
> similar behavior.  It seems to do similar caching, uses
> (eudc-query-with-words (split-string orig-string "[ \t]+")) like your
> code, tho your code passes an extra t arg to "try-all-servers".
> Maybe message.el should also use that?
> [...]

Thanks for your comments. I think there are (at least) two angles from
which we can look at this.

The first angle is the query semantics, and the "breadth and quality" of
search results, as you appear to be referring to. Under this angle, I
concur with your assessment that the improvements to the "breadth and
quality" of search results could probably have been retro-fitted onto
the existing code in message.el just as well. 

The second angle is how and where the functionality is embedded in the
wider structure of the code, and, as a consequence of this, what use
cases that enables. I think that it is under this second angle that my
patch provides the most advantages; at least that was my intention. As
you mention (message-expand-name-standard-ui), message.el sees itself as
being "in charge" of the completion UI, and I'll need to carefully
configure it to "stay away" from handling the completion UI to allow me
to use one of my liking. In fact I was when I started moving my setup to
use the corfu package [1] as my completion UI, when I cam eto the
conclusion that this patch would be needed to achieve my goal.

[1] https://github.com/minad/corfu

Looking beyond this (really sticking my head out the window even further
now), this patch gives us the option of moving "everything email
addresses" into EUDC. The next thing I'll spend some time on are EUDC
back-ends for ecomplete and mailabbrev. EUDC has a bbdb back-end
already. With that, all code that deals with the different sources for
email addresses could move from message.el to EUDC. In such a scenario,
message.el would need to do the marshalling between the different
completion contexts (email, newsgroup, subject, body, etc.) only. All
other special handling for email address completion that is there today,
would no longer be needed in message.el.


Hoping to have helped, and looking forward to your thoughts,

  --alexander