Subject: Re: bug#74944: 31.0.50; Double TAB does not pop up *Completions* buffer when completing filename with dashes

From: Visuwesh <[email-masked]>
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" <[email-masked]> writes:
>
>> Visuwesh <[email-masked]> 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.