unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Sean Whitton <spwhitton@spwhitton.name>
Cc: 67661@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
	67001@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer
Date: Sat, 09 Dec 2023 14:08:45 +0100	[thread overview]
Message-ID: <m1a5qjr09u.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <87lea3wpai.fsf@zephyr.silentflame.com> (Sean Whitton's message of "Sat, 09 Dec 2023 12:09:25 +0000")

Hi Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

> Previously you would get the icomplete in buffer completion.  Now,
> additionally, *Completions* pops up, but it doesn't make sense to have
> both.

I agree that having both interface together is a bit much, but AFAICT
that has been the case at least since Emacs 27 whenever the text before
point was the longest common prefix of several completion candidates.
For example, try completing "l" instead of "ls" in eshell.  On both
Emacs 27 and on master, this shows both the *Completions* buffer and the
in-buffer `icomplete` interface.  Is this what you get as well?

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Wed 06 Dec 2023 at 08:41pm +02, Eli Zaretskii wrote:
>
>> AFAICT, the above description of the problem is inaccurate.  The
>> *Completions* buffer would pop up in previous versions as well, but
>> only after a second TAB.  Whereas the in-buffer completion would show
>> after the first TAB.  Now in Emacs 30 after the first TAB nothing
>> happens, and after the second TAB you see the same display as
>> previously after the second TAB: both in-buffer completion and the
>> *Completions* buffer popped up.
>>
>> So I think the problem is that the first TAB does NOT show in-buffer
>> completion anymore in the above scenario.
>
> Commit 5416896d608 is responsible for the problem.
> It would seem that it turns off completion-in-region-mode too early.

IIUC, the problem of showing both interfaces is inherent to how
`icomplete-in-buffer` is implemented.  It's just that in this case of
completing "ls" the *Completions* doesn't show up at first because it's
an exact match.  What allowed the `icomplete` to show up is that
although the *Completions* buffer wasn't shown,
`completion-in-region-mode` would remain on, and that caused only the
`icomplete` interface to appear in this specific case.

The reason we now disable `completion-in-region-mode` when it doesn't
show the *Completions* buffer, is to avoid having the key bindings that
this minor mode sets up from lingering and shadowing other bindings.


If it doesn't make sense for `icomplete-in-buffer` to appear along with
the *Completions* buffer, perhaps `icomplete-in-buffer` should simply be
an alternative `completion-in-region-function`?


Best,

Eshel





  reply	other threads:[~2023-12-09 13:08 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-06 15:30 bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer Sean Whitton
2023-12-06 17:13 ` Juri Linkov
2023-12-06 18:14   ` Sean Whitton
2023-12-06 18:41 ` Eli Zaretskii
2023-12-07 11:42   ` Sean Whitton
2023-12-09 12:09   ` Sean Whitton
2023-12-09 13:08     ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-12-09 13:25       ` Eli Zaretskii
2023-12-09 14:13         ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 14:40           ` Eli Zaretskii
2023-12-09 15:22             ` Sean Whitton
2023-12-09 16:03             ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-09 16:07               ` Sean Whitton
2023-12-09 17:19                 ` Juri Linkov
2023-12-09 19:04                   ` Sean Whitton
2023-12-10 17:46                     ` Juri Linkov
2023-12-10 21:42                       ` Sean Whitton
2023-12-11 17:15                         ` Juri Linkov
2023-12-15 12:28                           ` Sean Whitton
2023-12-19 17:29                             ` Juri Linkov
2023-12-19 18:31                               ` Sean Whitton
2023-12-19 18:58                                 ` Juri Linkov
2023-12-20 10:34                                   ` Sean Whitton
2023-12-20 17:14                                     ` Juri Linkov
2023-12-22 12:00                                       ` Sean Whitton
2023-12-23 17:38                                         ` Juri Linkov
2023-12-29 17:47                                     ` Sean Whitton
2023-12-29 18:00                                       ` Sean Whitton
2023-12-29 19:27                                         ` Eli Zaretskii
2023-12-29 20:24                                           ` Sean Whitton
2023-12-30  6:30                                             ` Eli Zaretskii
2023-12-30 10:41                                               ` Sean Whitton
2023-12-30 17:52                                                 ` Juri Linkov
2023-12-30 19:43                                                   ` Sean Whitton
2023-12-30 17:50                                             ` Juri Linkov
2023-12-30 19:43                                               ` Sean Whitton
2023-12-31  8:29                                                 ` Juri Linkov
2024-01-10  3:12                                         ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 17:55                                           ` Sean Whitton
2024-01-17 19:18                                             ` Jim Porter
2023-12-09 16:22               ` Eli Zaretskii
2023-12-07 17:28 ` Juri Linkov
2023-12-07 22:04   ` Sean Whitton
2023-12-08  6:28     ` Eli Zaretskii
2023-12-08 10:19       ` Sean Whitton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1a5qjr09u.fsf@dazzs-mbp.home \
    --to=bug-gnu-emacs@gnu.org \
    --cc=67001@debbugs.gnu.org \
    --cc=67661@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=me@eshelyaron.com \
    --cc=spwhitton@spwhitton.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).