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 12:39:46 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: kahatlen@gmail.com, 60411@debbugs.gnu.org, monnier@iro.umontreal.ca, 
>     juri@linkov.net
> 
> 
> >
> > That's very surprising to hear.  AFAIU, it just looks for some special 
> > text property (in next-completion).  So it sounds like a very simple 
> > breakage of logic, where "next" means "the first one" when you are 
> > exactly at BOB.
> >
> 
> The problem is that minibuffer-next-completion is supposed to move to the 
> first completion when it is called for the first time, to the next 
> completion when it is called for the Nth time, and to the first completion 
> again when it is called for the Mth time (where M is the number of 
> completion candidates).

Right.

> If point is at BOB, and if there is nothing before the first completion, 
> next-completion finds that there is a text property there, and therefore 
> moves to the end of the current completion (the first one) and to the 
> beginning of the next completion, with the two calls to 
> next-single-property-change.
> 
> There is nothing in the current logic of the code with which it is 
> possible to make a distinction between "this is the first call" and "this 
> is not the first call".

Didn't you just say that the difference between "first" and "next" is
"the first call"?  Can't we make the logic be based on that instead of
assuming that the format produces an empty string under certain
conditions?