GNU bug report logs - #74944
31.0.50; Double TAB does not pop up *Completions* buffer when completing filename with dashes

Previous Next

Package: emacs;

Reported by: Visuwesh <visuweshm <at> gmail.com>

Date: Wed, 18 Dec 2024 12:51:01 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

From: Visuwesh <visuweshm <at> gmail.com>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 74944 <at> debbugs.gnu.org
Subject: bug#74944: 31.0.50; Double TAB does not pop up *Completions* buffer when completing filename with dashes
Date: Thu, 26 Dec 2024 18:41:35 +0530
[ஞாயிறு டிசம்பர் 22, 2024] Manuel Giraud wrote:

> Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Visuwesh <visuweshm <at> gmail.com> writes:
>>
>>> When completing filenames with dashes in them inside a shell-buffer,
>>> double TAB does not pop open the *Completions* buffer because it
>>> conflicts with argument completion.  To reproduce,
>>>
>>>     1. cd /tmp
>>>     2. mkdir test; cd test
>>>     3. touch blah_blah-pos-1.xyz; touch wowow-pos-1.xyz
>>>     4. Go to this directory in a shell buffer
>>>     5. Type rm pos.xyz TAB
>>>     6. Observe how it completes to `rm -pos-1.xyz'
>>>     7. Press TAB again and observe *Completions* buffer not popping up
>>
>> Hi Visuwesh,
>>
>> I can reproduce this.  FWIW, by instrumenting
>> `shell-filename-completion' with edebug, I can see that there is a
>> correct *Completions* buffer at some point but it "disappears" later.
>> I'll try to investigate it further.
>
> Hi,
>
> I did some more tests but this issue is tricky for me and I'm not
> familiar with the completion framework.  

Thank you for looking into this.  I have probably lower familiarity with
it than you.

> Anyway, here is what I did (and think I understood):
>
>         - First, I instrument `shell-filename-completion' with edebug
>         
>         - I enter "rm -pos-1.xyz" and hit Tab with the point is right
>           after the 'z'
>
>         - Edebug is trigerred and I can step through it hitting Space.
>
>         - All seems fine, but at the end of this
>           `shell-filename-completion' call (which returns something),
>           Edebug is triggered again this time with the point placed just
>           before the first '-'
>
> I really don't understand why there is what seems to be a *second* call
> to `shell-filename-completion' while the first one seems to have
> succeeded.  

The second call which moves the before the first '-' makes sense to me
since to complete further one, one has to insert text before that
character.  This happens elsewhere too so I am not exactly surprised.
However, I think this is where the capf gets stuck since Emacs thinks it
has to complete an option / a flag and the completion engine stops.

This is my guess, anyway.




This bug report was last modified 158 days ago.

Previous Next


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