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

Package: emacs;

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


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 10:52:11 +0200
> Date: Fri, 06 Jan 2023 08:22:39 +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?




This bug report was last modified 2 years and 130 days ago.

Previous Next


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