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
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
Message #77 received at 60411 <at> debbugs.gnu.org (full text, mbox):
>
> Didn't you just say that the difference between "first" and "next" is
> "the first call"? Can't we make the logic be based on that instead of
> assuming that the format produces an empty string under certain
> conditions?
>
As far as I can see, no. What is also possible, if it's the condition
that you don't like, is to insert that invisible line unconditionally,
like this:
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index f47299bd0d..09125772f3 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2275,6 +2275,10 @@ display-completion-list
(with-current-buffer standard-output
(goto-char (point-max))
+ ;; Insert an invisible line, otherwise the first call to
+ ;; 'minibuffer-next-completion' might select the second
+ ;; completion candidate. See bug#60411.
+ (insert (propertize "\n" 'invisible t))
(when completions-header-format
(insert (format completions-header-format (length completions))))
(completion--insert-strings completions group-fun)))
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.