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

Previous Next

Full log

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: 74944 <at> debbugs.gnu.org, Visuwesh <visuweshm <at> gmail.com>
Subject: Re: bug#74944: 31.0.50; Double TAB does not pop up *Completions*
 buffer when completing filename with dashes
Date: Sun, 22 Dec 2024 12:45:00 +0100

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.  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 backtrace from the first call looks like this:

--8<---------------cut here---------------start------------->8---
  shell-command-completion()
  run-hook-with-args-until-success(shell-command-completion)
  comint-completion-at-point()
  completion--capf-wrapper(comint-completion-at-point all)
  run-hook-wrapped(completion--capf-wrapper comint-completion-at-point all)
  completion-at-point()
  funcall-interactively(completion-at-point)
  call-interactively(completion-at-point nil nil)
  command-execute(completion-at-point)
--8<---------------cut here---------------end--------------->8---

And here is the backtrace from this "second" call:
--8<---------------cut here---------------start------------->8---
  shell-command-completion()
  run-hook-with-args-until-success(shell-command-completion)
  comint-completion-at-point()
  #f(compiled-function () #<bytecode 0x347c002d48b3cbc>)()
  completion-in-region--postch()
--8<---------------cut here---------------end--------------->8---
-- 
Manuel Giraud

Previous Next

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