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 15:26:32 +0200
> Date: Fri, 06 Jan 2023 13:10:18 +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
> 
> > 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.

But let's wait for Stefan to chime in.




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.