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: Juri Linkov <juri <at> linkov.net>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Knut Anders Hatlen <kahatlen <at> gmail.com>, 60411 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil
Date: Thu, 05 Jan 2023 19:37:34 +0200

>> 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.

Previous Next

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