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

Previous Next

Full log

View this message in rfc822 format

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: bug#59314: 29.0.50; EUDC and message-mode header completion
Date: Sat, 10 Dec 2022 09:27:21 -0500

Hi Alexander,

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

> another lengthy explanation, for which apologies up front!

OK, trimmed it down.

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

Previous Next

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