bug#59314: 29.0.50; EUDC and message-mode header completion

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

Hi Alexander,

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> another lengthy explanation, for which apologies up front!

OK, trimmed it down.

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> [...]
>> OK, but then (to lengthen the conclusion) message--name-table ignores
>> the default value of 'completion-styles' (or if it doesn't, it should),
>> and so the default global value of 'completion-styles' should not have
>> any bearing on any of these tests we're doing.  Is that correct?
>> [...]
>
> Yes, that's correct.
>
> message--name-table responds to the metadata action by returning a list
> containing (category . email), which instructs the completion-at-point
> machinery to ignore the global completion-styles variable, and instead
> consult the completion-category-defaults and
> completion-category-overrides alists for the completion style defined
> under the 'email entry (if one exists).
>
> With an eye to fixing this bug, I think there are three plus one
> scenarios to look at.

[...]

The scenario I'd like you to make work with a minimal patch is:
Scenario 3+1 + (setq message-expand-name-standard-ui t).

Did you try that?  I'm pretty sure if you get that working you'll find
that we don't need eudc-capf-complete in completion-at-point-functions
(yet), since what was there will already do what eudc-capf-complete was
trying to achieve.

Basically, this whole part of the discussion I've been thinking in terms
of "(setq message-expand-name-standard-ui t)".

When message-expand-name-standard-ui is nil, I think we've determined
that eudc-capf-complete's presence in completion-at-point-functions
breaks EUDC functionality.  Do you concur?  If that's the case we should
probably remove eudc-capf-complete from completion-at-point-functions
for Emacs 29.1, since that would represent a regression.

I now understand that the intent of the code that was there before we
added eudc-capf-complete was:

message-expand-name-standard-ui nil => use EUDC multi-selector UI
message-expand-name-standard-ui t   => use completion-at-point selector UI

But the second case was already broken before we added
eudc-capf-complete.  I want to understand and fix that case.

(I'm rushing responses here, I'll dedicate more time to real testing
maybe tomorrow, but I'm hoping you'll beat me to it with a minimal patch
:-))

Thanks,
Thomas