bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-i


From: Sean Whitton
Subject: bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer
Date: Wed, 20 Dec 2023 10:34:09 +0000
User-agent: Gnus/5.13 (Gnus v5.13)

Hello,

On Tue 19 Dec 2023 at 08:58pm +02, Juri Linkov wrote:

>>> Both are already shown: M-C-i pops up the *Completions* buffer
>>> and activates in-buffer candidates.  If you want M-C-i only
>>> to activate in-buffer candidates, then the line above
>>> should be removed from `completion--in-region`.
>>
>> When I said "provide both", I meant both your idea of how the feature
>> should work, and my idea of how it should work.  I didn't mean both the
>> in-buffer candidates and the *Completions* buffer.
>>
>> What you've said isn't true, though: a single TAB, which is bound to
>> completion-at-point in Eshell, does not show in-buffer candidates, nor
>> does it pop up the *Completions* buffer.
>
> Because ls<TAB> is complete, but not unique.  So it requires the second TAB,
> exactly as in the minibuffer.  A single TAB does this on incomplete candidate,
> e.g. l<TAB>.

Ah.  This is not the bug.  We may have been subtly miscommunicating.
I am talking about completing the first argument to the command, not
the 'ls' command itself.

So for example:

1. emacs -q
2. (setopt icomplete-in-buffer t)
3. M-x icomplete-mode
4. M-x eshell
5. cd ~/src/emacs/
6. ls l<TAB>

It takes a second <TAB> to have Emacs display leim, lib, lib-src, lisp etc..

-- 
Sean Whitton





reply via email to

[Prev in Thread] Current Thread [Next in Thread]