From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
To: Alexander Adolf <alexander.adolf@condition-alpha.com>
Cc: Eric Abrahamsen <eric@ericabrahamsen.net>, 59314@debbugs.gnu.org
Subject: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Thu, 08 Dec 2022 17:58:56 -0500 [thread overview]
Message-ID: <m3bkoda4en.fsf@fitzsim.org> (raw)
In-Reply-To: <dcac3ba0d9288e277bb9ebeff6e0dc6c@condition-alpha.com> (Alexander Adolf's message of "Thu, 08 Dec 2022 23:34:39 +0100")
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
next prev parent reply other threads:[~2022-12-08 22:58 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 18:05 bug#59314: 29.0.50; EUDC and message-mode header completion Eric Abrahamsen
2022-11-16 19:18 ` Thomas Fitzsimmons
2022-11-16 19:46 ` Eric Abrahamsen
2022-11-16 20:54 ` Thomas Fitzsimmons
2022-11-16 22:28 ` Eric Abrahamsen
2022-11-17 1:34 ` Thomas Fitzsimmons
2022-11-17 2:04 ` Eric Abrahamsen
2022-11-17 1:16 ` Eric Abrahamsen
2022-11-17 3:32 ` Thomas Fitzsimmons
2022-11-17 3:28 ` Thomas Fitzsimmons
2022-11-18 4:21 ` Eric Abrahamsen
2022-11-19 7:42 ` Thomas Fitzsimmons
2022-11-22 0:15 ` Eric Abrahamsen
2022-11-22 15:21 ` Thomas Fitzsimmons
2022-11-24 7:24 ` Thomas Fitzsimmons
2022-11-24 22:09 ` Eric Abrahamsen
2022-11-24 9:53 ` Thomas Fitzsimmons
2022-12-01 15:46 ` Alexander Adolf
2022-12-01 16:02 ` Eric Abrahamsen
2022-12-01 15:48 ` Alexander Adolf
2022-12-01 17:49 ` Eric Abrahamsen
2022-12-02 2:50 ` Thomas Fitzsimmons
2022-12-06 20:40 ` Alexander Adolf
2022-12-06 20:52 ` Thomas Fitzsimmons
2022-12-06 23:29 ` Alexander Adolf
2022-12-07 1:51 ` Thomas Fitzsimmons
2022-12-07 3:14 ` Thomas Fitzsimmons
2022-12-07 22:10 ` Alexander Adolf
2022-12-07 22:21 ` Thomas Fitzsimmons
2022-12-08 22:34 ` Alexander Adolf
2022-12-08 22:58 ` Thomas Fitzsimmons [this message]
2022-12-10 1:40 ` Alexander Adolf
2022-12-10 14:27 ` Thomas Fitzsimmons
2022-12-12 22:10 ` Alexander Adolf
2022-12-14 1:34 ` Thomas Fitzsimmons
2022-12-14 18:07 ` Alexander Adolf
2022-12-15 3:32 ` Thomas Fitzsimmons
2022-12-19 16:09 ` Alexander Adolf
2022-12-21 17:39 ` Thomas Fitzsimmons
2022-12-11 16:08 ` Alexander Adolf
2022-12-12 12:31 ` Thomas Fitzsimmons
2022-12-07 22:20 ` Alexander Adolf
2023-02-11 3:30 ` Thomas Fitzsimmons
2023-01-31 13:04 ` Julien Cubizolles
2023-02-05 0:48 ` Thomas Fitzsimmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3bkoda4en.fsf@fitzsim.org \
--to=fitzsim@fitzsim.org \
--cc=59314@debbugs.gnu.org \
--cc=alexander.adolf@condition-alpha.com \
--cc=eric@ericabrahamsen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).