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

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: kahatlen <at> gmail.com, 60411 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, juri <at> linkov.net
Subject: bug#60411: 29.0.60; minibuffer-next-completion skips first candidate when completions-header-format and completion-show-help are nil
Date: Fri, 06 Jan 2023 13:40:16 +0200

> Date: Fri, 06 Jan 2023 09:01:08 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: kahatlen <at> gmail.com, 60411 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, 
>     juri <at> linkov.net
> 
> 
> >>>> Stefan and Eli, do you agree with that conclusion?
> >>>
> >>> I admit that I've lost the line of reasoning here (too much of the 
> >>> previous context is being elided, forcing me to re-read the entire 
> >>> discussion).  Which code is proposed for the release branch, and how 
> >>> will Emacs behave with that code in this particular use case?
> >>
> >> It's this patch.  It adds an invisible empty line at the beginning of 
> >> *Completions* when completions-header-format is not a string (in 
> >> particular, nil) or an empty string.
> >
> > What is the significance of these two special values of 
> > completions-header-format?  Is it that you want to test whether the 
> > first candidates starts at buffer position 1 in the *Completions* 
> > buffer?  Then why not test for that explicitly?
> >
> 
> When completions-header-format is nil or an empty string, no completion 
> header "NNN possible completions:\n" is inserted in *Completions*. 
> Because of this, minibuffer-next-completion (bound to M-<down> by 
> default), which is supposed to select the first completion when it is 
> called for the first time, erroneously selects the second completion. 
> The fact that "something" (the completion header and/or the help text 
> "Click on a completion to select it...") must exist in *Completions* 
> before the first completion candidate is more or less hardcoded in the 
> logic of minibuffer-next-completion.

Then why not change that logic in minibuffer-next-completion to be
smarter about this?

What you suggest is too ad-hoc-ish, and any future change to the
possible values of completions-header-format will risk breaking the
condition you propose.

Or maybe what minibuffer-next-completion does should be rethought?
Why does it assume that the first candidate is on the second line?
what if it's on the third line instead?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.