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

Message #86 received at 60411 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: kahatlen <at> gmail.com, Gregory Heytings <gregory <at> heytings.org>,
 60411 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: 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 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).

We could try and add a boolean buffer-local variable to remember if
we've already used `minibuffer-next-completion`.  Gregory said he tried
and bumped into further problems.  It would arguably be cleaner to do
that (and fix whichever other problem shows up), but I haven't had the
time to look into that.

I suspect in the mean time Gregory's hack might be an OK workaround
(invisible text tends to come with its own problems, so I'd prefer if
we install it conditionally rather than unconditionally, BTW), but
it should have a comment with a FIXME.


        Stefan

Previous Next

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