bug#59314: 29.0.50; EUDC and message-mode header completion

[Thomas Fitzsimmons]

Hi Alexander,

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

> Thomas Fitzsimmons <fitzsim@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@bbdb.gnu.org>"
 "Emacs ERT4 <emacs-ert-test-4@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