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

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: kahatlen <at> gmail.com, gregory <at> heytings.org, 60411 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil
Date: Fri, 06 Jan 2023 20:11:10 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Gregory Heytings <gregory <at> heytings.org>,  kahatlen <at> gmail.com,
>   60411 <at> debbugs.gnu.org,  juri <at> linkov.net
> Date: Fri, 06 Jan 2023 12:51:41 -0500
> 
> >> > Then why not change that logic in minibuffer-next-completion to be 
> >> > smarter about this?
> >> I (and Stefan) already tried this, it doesn't seem to be feasible with a 
> >> small and safe change.
> > 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 how to determine "this is the first time".  Currently we
> encode that information indirectly by the fact that point as at BOB
> (and is not on an actual completion).

Gregory just suggested a patch which does that in a fairly simple and
straightforward way.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.