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 #83 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:
>
> If we cannot come up with any better ideas (which again surprises me),
> then unconditionally adding such a newline is better.
>
Okay. I just had another look at this bug, and the patch below seems to
work, too. I find it much trickier and adhocish, though.
diff --git a/lisp/simple.el b/lisp/simple.el
index 63479e9ce0..75f9956548 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9698,6 +9698,14 @@ next-completion
(let ((tabcommand (member (this-command-keys) '("\t" [backtab])))
pos)
(catch 'bound
+ (when (and (= n 1)
+ (= (point) (point-min))
+ (get-text-property (point) 'mouse-face)
+ (not (get-text-property (point) 'first-completion)))
+ (let ((inhibit-read-only t))
+ (add-text-properties (point) (1+ (point)) '(first-completion t)))
+ (setq n 0))
+
(while (> n 0)
(setq pos (point))
;; If in a completion, move to the end of it.
This bug report was last modified 2 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.