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

Package: emacs;

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Knut Anders Hatlen <kahatlen <at> gmail.com>, 60411 <at> debbugs.gnu.org
Subject: bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil
Date: Sun, 01 Jan 2023 18:56:30 +0000
>
> 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.

>
> (when completions-highlight-face
>   (setq-local cursor-face-highlight-nonselected-window t))
>
> 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.





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.