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: Wed, 14 Dec 2022 22:32:43 -0500

Hi Alexander,

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

> Thomas Fitzsimmons <fitzsim <at> fitzsim.org> writes:
>
>> [...]
>> This may be a clue; while I was experimenting, I found that this:
>>
>> @@ -8432,7 +8438,7 @@ message--name-table
>>                            (all-completions string
>>                                             (ecomplete-completion-table 'mail)
>>                                             pred)))))
>> -	   (if action candidates (try-completion string candidates))))))))
>> +	   (if action (cdr candidates) (try-completion string candidates))))))))
>> [...]
>
> Interesting; thanks for sharing this. Effectively, you're dropping the
> first entry from the `candidates` list before returning it. What does
> your `candidates` list contain at that point (before removal)?

("Emacs ERT3 <emacs-ert-test-3 <at> bbdb.gnu.org>"
 "Emacs ERT4 <emacs-ert-test-4 <at> bbdb.gnu.org>")

> I have some observations to share, too.
>
> When the lambda function returned by `message--name-table` is called
> with 't as the action argument, that is when it is expected to return
> completion candidates, I have modified the code to return a static list
> so I can experiment. It turns out that the breakage is triggered by the
> _last_ candidate in that list. If & when the last element contains
> white-space in what would be the "common prefix", then things go south.
> All other candidates in that list may contain generous amounts of
> white-space anywhere, and things will still work as expected (selection
> UI is presented upon the second TAB key press).

OK, interesting; maybe we've found a bug in the completion engine
itself.

> The second observation is related to completion styles. With our
> test-case, 'partial-completion does not produce useful results for my
> standards. Perhaps a "collateral conclusion" will be that 'substring is
> all that is needed when completing email recipients? Let's see.

Maybe, but it seems like the "completion-category-defaults" logic that
you pointed out earlier is working, such that when completion is
attempted, 'substring is in completion-styles.  Here is the debugging
patch I have to print completion styles in-context:

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5faa3c8d4e8..455135628c8 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1191,7 +1191,7 @@ completion--nth-completion
                                (error "Invalid completion style %s" style))
                            string table pred point)))
                (and probe (cons probe style))))
-           (completion--styles md)))
+           (let ((styles (completion--styles md))) (message "STYLES: %S" styles) styles)))

When I press TAB, it prints:

STYLES: (substring partial-completion basic emacs22)

even though globally, completion-styles is set to its default,
(basic partial-completion emacs22)

> I'll now dig further into minibuffer.el and what happens in the
> 'substring completion style code with the last element of the candidates
> list.

OK, it sounds like you're close to finding the root cause.

Thanks,
Thomas

Previous Next

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