GNU bug report logs - #59314
29.0.50; EUDC and message-mode header completion

Previous Next

Full log

Message #98 received at 59314 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, 59314 <at> debbugs.gnu.org
Subject: Re: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Thu, 08 Dec 2022 17:58:56 -0500

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

> Thomas Fitzsimmons <fitzsim <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.