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: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
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 12:55:22 -0500

>> Yuck.  I get the impression that it would be cleaner to fix "the first
>> call to `minibuffer-next-completion`" instead.
> That was my impression, too.  Until I tried to fix "the first call to
> `minibuffer-next-completion`".  But I may have missed something, of course.

Hmm...  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?).

This is made more muddy by

      (when completions-highlight-face
        (setq-local cursor-face-highlight-nonselected-window t))

which changes the behavior of *Completions* depending on whether
`minibuffer-next-completion` has been used or not since the
*Completions* buffer was setup.
[ "Fixing" this might require extending
  `cursor-face-highlight-nonselected-window` so that it can indicate
  whether to highlight when either *Completion* or the minibuffer is
  selected).  ]

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.


        Stefan

Previous Next

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