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: Sat, 10 Dec 2022 09:27:21 -0500 [thread overview]
Message-ID: <m3wn6z8hbq.fsf@fitzsim.org> (raw)
In-Reply-To: <4d1810369df651d02ceeb522b8f05370@condition-alpha.com> (Alexander Adolf's message of "Sat, 10 Dec 2022 02:40:35 +0100")
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
next prev parent reply other threads:[~2022-12-10 14:27 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
2022-12-10 1:40 ` Alexander Adolf
2022-12-10 14:27 ` Thomas Fitzsimmons [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3wn6z8hbq.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.