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

[Thomas Fitzsimmons]

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

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> [...]
>>> For one, you are no longer adding `eudc-capf-complete` to
>>> `completion-at-point-functions` in message mode. This seems fine given
>>> that we are not there yet to make `eudc-capf-complete` the default thing
>>> to happen in 29.
>>
>> To be clear, I wasn't going to push a patch to remove that, at least not
>> yet.  It's not making anything worse, so might as well leave it as-is.
>
> I see. Please kindly ignore yesterday's path then, please.
>
>>> [...]
>> I'm trying to get message--name-table's EUDC support working.  I only
>> wanted to remove eudc-capf-complete from the debugging equation, because
>> message--name-table existed way before eudc-capf-complete was
>> introduced.
>>
>> I want to understand why it doesn't work (why it results in the " <..."
>> expansion).  I haven't delved deep enough into the completion-at-point
>> to figure that out.  I was hoping with your experience writing
>> eudc-capf-complete that you'd know what was wrong with
>> message--name-table's EUDC support.
>
> I'll look into `message--name-table` and will find out what breaks with
> the " <" prefix. Please allow until Friday USA time (assuming you're
> there?); it's late already over here (Europe).

Sure, thank you, please take your time.  I haven't digested the diagram
you posted yet, but I'll have a look when I get a chance.

>> I don't think completion-styles should have any bearing on this.
>> message--name-table's EUDC support has to be made to work with the
>> default completion-styles setting.  Do you know how to do that?
>
> The thing is, they do have a bearing, and there is no way to avoid that.
> `completion-at-point` filters the candidates returned by the
> `completion-at-point-functions`, and it uses the completion style (set
> by either `completion-styles`, or via a completion category signalled in
> a completion table) for this.
>
> When the completion table does not signal a completion style,
> `completion-at-point` uses the value of `completion-styles` to filter
> the candidates. Only matching candidates will be presented in any UI.
> The default value of `completion-styles` is '(basic partial-completion
> emacs22). Which - according to the manual [1] - effects the following:
>
> ---------------------------- Begin Quote -----------------------------
> basic
>
>    A matching completion alternative must have the same beginning as the
>    text in the minibuffer before point. Furthermore, if there is any
>    text in the minibuffer after point, the rest of the completion
>    alternative must contain that text as a substring.
>
> partial-completion
>
>    This aggressive completion style divides the minibuffer text into
>    words separated by hyphens or spaces, and completes each word
>    separately. (For example, when completing command names, ‘em-l-m’
>    completes to ‘emacs-lisp-mode’.)
>
>    Furthermore, a ‘*’ in the minibuffer text is treated as a wildcard—it
>    matches any string of characters at the corresponding position in the
>    completion alternative.
>
> emacs22
>
>    This completion style is similar to basic, except that it ignores the
>    text in the minibuffer after point. It is so-named because it
>    corresponds to the completion behavior in Emacs 22.
> ----------------------------- End Quote ------------------------------
> [1] 
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Completion-Styles.html
>
> I.e. the default setting of `completion-styles` will match for
> candidates that have the search string at their beginning only. Example:
> when the text before point is "foo", the candidates "foo", "foox", and
> "foobar" will be shown, but not the candidate "barfoo".
>
> Clearly, this is fairly useless for email address completion. Thus, the
> function `message--name-table` in message.el begins like this:
>
> ---------------------------- Begin Quote -----------------------------
> (defun message--name-table (orig-string)
>   (let ((orig-words (split-string orig-string "[ \t]+"))
>         eudc-responses
>         bbdb-responses)
>     (lambda (string pred action)
>       (pcase action
>         ('metadata '(metadata (category . email)))
> [...]
> ----------------------------- End Quote ------------------------------
>
> In the last quoted line, it return the list '(metadata (category .
> email)) in response to the 'metadata action.
>
> When message.el is loaded, the init code there does this:
>
> ---------------------------- Begin Quote -----------------------------
> (add-to-list 'completion-category-defaults '(email (styles substring
>                                                            
> partial-completion)))
> ----------------------------- End Quote ------------------------------
>
> This defines the 'email completion category to imply the completion
> styles '(substring partial-completion). Thus, whenever
> `message--name-table` comes into play, these completion styles will be
> in effect.

I see, hmm.  That's quite complicated.  Nice analysis, thank you.

> Long story, short conclusion: you can't do meaningful email address
> completion with the default value of `completion styles`.

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?

Thanks,
Thomas