GNU bug report logs -
#67661
30.0.50; *Completions* has started popping up for icomplete-in-buffer
Previous Next
Reported by: Sean Whitton <spwhitton <at> spwhitton.name>
Date: Wed, 6 Dec 2023 15:31:02 UTC
Severity: normal
Fixed in version 30.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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
This bug report was last modified 1 year and 184 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.