bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 06 Jan 2023 09:01:08 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: kahatlen@gmail.com, 60411@debbugs.gnu.org, monnier@iro.umontreal.ca, 
>     juri@linkov.net
> 
> 
> >>>> Stefan and Eli, do you agree with that conclusion?
> >>>
> >>> I admit that I've lost the line of reasoning here (too much of the 
> >>> previous context is being elided, forcing me to re-read the entire 
> >>> discussion).  Which code is proposed for the release branch, and how 
> >>> will Emacs behave with that code in this particular use case?
> >>
> >> It's this patch.  It adds an invisible empty line at the beginning of 
> >> *Completions* when completions-header-format is not a string (in 
> >> particular, nil) or an empty string.
> >
> > What is the significance of these two special values of 
> > completions-header-format?  Is it that you want to test whether the 
> > first candidates starts at buffer position 1 in the *Completions* 
> > buffer?  Then why not test for that explicitly?
> >
> 
> When completions-header-format is nil or an empty string, no completion 
> header "NNN possible completions:\n" is inserted in *Completions*. 
> Because of this, minibuffer-next-completion (bound to M-<down> by 
> default), which is supposed to select the first completion when it is 
> called for the first time, erroneously selects the second completion. 
> The fact that "something" (the completion header and/or the help text 
> "Click on a completion to select it...") must exist in *Completions* 
> before the first completion candidate is more or less hardcoded in the 
> logic of minibuffer-next-completion.

Then why not change that logic in minibuffer-next-completion to be
smarter about this?

What you suggest is too ad-hoc-ish, and any future change to the
possible values of completions-header-format will risk breaking the
condition you propose.

Or maybe what minibuffer-next-completion does should be rethought?
Why does it assume that the first candidate is on the second line?
what if it's on the third line instead?