GNU bug report logs - #67661
30.0.50; *Completions* has started popping up for icomplete-in-buffer

Previous Next

Full log

Message #114 received at 67661 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 67661 <at> debbugs.gnu.org, me <at> eshelyaron.com, juri <at> linkov.net
Subject: Re: bug#67661: 30.0.50; *Completions* has started popping up for
 icomplete-in-buffer
Date: Sat, 30 Dec 2023 08:30:29 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: me <at> eshelyaron.com, 67661 <at> debbugs.gnu.org
> Date: Fri, 29 Dec 2023 20:24:26 +0000
> 
> On Fri 29 Dec 2023 at 09:27pm +02, Eli Zaretskii wrote:
> 
> > To which entry in Emacs 29's NEWS would this be related?
> 
> I'm talking about how Juri fixed icomplete-in-buffer for Emacs 29, and
> how it's now working differently.  Juri's fix wasn't noted in NEWS.29,
> so there isn't a relevant entry.

I thought you were suggesting to add something to NEWS in Emacs 29.
If there's no suitable entry there, then I wonder what did you have in
mind for Emacs 29 in this area.

> Thus, I propose adding a NEWS.30 entry like this:
> 
>     There have been some changes which normalise some behaviour of
>     in-buffer completion that affect users of icomplete-in-buffer.
> 
>     Firstly, completion-auto-help now governs icomplete-in-buffer,
>     whereas previously it affected only minibuffer completion.  You may
>     wish to review any existing customisation for completion-auto-help
>     if in-buffer completion behaves in a way that surprises you.
> 
>     Secondly, the *Completions* buffer now always pops up at the same
>     time that Icomplete displays its in-buffer completion.  If you would
>     prefer to see only Icomplete's display, which is what you might be
>     used to, you could use
> 
>         (advice-add 'completion-at-point :after #'minibuffer-hide-completions)

AFAIU, this should also mention changes in Emacs 29 wrt previous
versions.

Also, the entry should in terms of user-facing behavior, not in terms
of how code works.  It should also be more concrete; phrases like "you
may wish to review existing customizations" are too vague to be
useful.

The last paragraph seems to indicate we lack some user option or a
variable to get back the old behavior, since using advice-add is less
friendly than flipping a variable.

(IMO, we are making too many backward-incompatible changes in this
area lately.  But that's me.)

Previous Next

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