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

[Alexander Adolf]

Hello Thomas,

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)?


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).

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.

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.


Cheers,

  --alexander