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:

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