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

[Gregory Heytings]

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