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

[Juri Linkov <juri@linkov.net>]

>> I think the crux of the matter is that the state in which we are at the
>> beginning (when creating the *Completions* buffer) is unclear/accidental
>> (is the first completion already selected or not?).
>
> Exactly.
>
>> It's not clear to me how to "make this right", but maybe a "better ugly
>> hack" is to work with the above `setq-local`, i.e. if
>> `cursor-face-highlight-nonselected-window` is still nil (in which case,
>> the cursor-face hilighting should be currently off), consider that
>> `minibuffer-next-completion` should move to the *first* completion rather
>> than to the next.
>
> I thought about that solution, but what if someone sets
> completion-highlight-face to nil?  I also tried to add another buffer-local
> variable to distinguish the first and later calls to
> minibuffer-next-completion, but that didn't work in all cases either.

Then I guess your insert-invisible-\n patch is the simplest way
to enforce such a long-standing rule that no candidate is selected
in the completions buffer initially, even when it has no visible header.
And definitely this is the safest solution for the release branch.