GNU bug report logs -
#60411
29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil
Previous Next
Reported by: Knut Anders Hatlen <kahatlen <at> gmail.com>
Date: Thu, 29 Dec 2022 21:26:02 UTC
Severity: normal
Fixed in version 29.0.60
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
>
> 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).
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".
This bug report was last modified 2 years and 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.