Subject: Re: bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil

From: Gregory Heytings <[email-masked]>
Date: Fri, 06 Jan 2023 17:07:21 +0000

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