GNU bug report logs - #79151
31.0.50; eshell does not complete filename arguments with tramp

Previous Next

To reply to this bug, email your comments to 79151 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; eshell does not complete filename arguments with tramp
Date: Sat, 02 Aug 2025 12:59:19 +0200

After an unknown command there is a discrepancy how file names are
completed depending on if the current directory is local or remote.

In Eshell I enter some command unknown to Pcomplete and then I try to
complete a filename:

~/local $ mycommand fileprefix<TAB> --> Completion works
/ssh:user <at> host:~/ $ mycommand fileprefix<TAB> --> Completion does not work
/su::/ $ mycommand fileprefix<TAB> --> Completion does not work

I can fix the problem with the following advice which disables the
`pcomplete-remote-file-ignore' override:

(advice-add 'eshell-complete-parse-arguments
 :after (lambda () (kill-local-variable 'pcomplete-remote-file-ignore)))

Is this expected or is this a bug? What is the reasoning behind
disabling file name completion? I would like to always have the ability
to complete file names.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-07-29
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --prefix=$HOME/.local/share/emacs
 --without-compress-install --with-tree-sitter --with-native-compilation
 --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
 --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
 --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
 'CFLAGS=-O3 -mtune=native -march=native''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>, 79151 <at> debbugs.gnu.org
Cc: Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Sat, 2 Aug 2025 11:46:34 -0700

CCing Michael, since I don't know much about the interaction between 
Pcomplete and Tramp here.

On 8/2/2025 3:59 AM, Daniel Mendler via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> After an unknown command there is a discrepancy how file names are
> completed depending on if the current directory is local or remote.
> 
> In Eshell I enter some command unknown to Pcomplete and then I try to
> complete a filename:
> 
> ~/local $ mycommand fileprefix<TAB> --> Completion works
> /ssh:user <at> host:~/ $ mycommand fileprefix<TAB> --> Completion does not work
> /su::/ $ mycommand fileprefix<TAB> --> Completion does not work
> 
> I can fix the problem with the following advice which disables the
> `pcomplete-remote-file-ignore' override:
> 
> (advice-add 'eshell-complete-parse-arguments
>   :after (lambda () (kill-local-variable 'pcomplete-remote-file-ignore)))
> 
> Is this expected or is this a bug? What is the reasoning behind
> disabling file name completion? I would like to always have the ability
> to complete file names.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 79151 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Sat, 02 Aug 2025 21:15:46 +0200

Jim Porter <jporterbugs <at> gmail.com> writes:

> CCing Michael, since I don't know much about the interaction between Pcomplete
> and Tramp here.

Thanks.

The problem was introduced by commit 26ca3e84e167f975afb4e9e9a838935bfe4a19a7.
I don't understand the reasoning given in the comment:

    ;; Determine, whether remote file names shall be completed.  They
    ;; shouldn't for external commands, or when in a pipe.  Respect
    ;; also `eshell-cmpl-remote-file-ignore', which could be set by
    ;; the user.

I often want to complete file names in when I am executing a command in
a remote directory, also for external commands, and maybe also as part
of a pipe.

> On 8/2/2025 3:59 AM, Daniel Mendler via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
>> After an unknown command there is a discrepancy how file names are
>> completed depending on if the current directory is local or remote.
>> In Eshell I enter some command unknown to Pcomplete and then I try to
>> complete a filename:
>> ~/local $ mycommand fileprefix<TAB> --> Completion works
>> /ssh:user <at> host:~/ $ mycommand fileprefix<TAB> --> Completion does not work
>> /su::/ $ mycommand fileprefix<TAB> --> Completion does not work
>> I can fix the problem with the following advice which disables the
>> `pcomplete-remote-file-ignore' override:
>> (advice-add 'eshell-complete-parse-arguments
>>   :after (lambda () (kill-local-variable 'pcomplete-remote-file-ignore)))
>> Is this expected or is this a bug? What is the reasoning behind
>> disabling file name completion? I would like to always have the ability
>> to complete file names.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79151 <at> debbugs.gnu.org, Jim Porter <jporterbugs <at> gmail.com>
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Mon, 04 Aug 2025 09:52:15 +0200

Daniel Mendler <mail <at> daniel-mendler.de> writes:

Hi Daniel & Jim,

>     ;; Determine, whether remote file names shall be completed.  They
>     ;; shouldn't for external commands, or when in a pipe.  Respect
>     ;; also `eshell-cmpl-remote-file-ignore', which could be set by
>     ;; the user.
>
> I often want to complete file names in when I am executing a command in
> a remote directory, also for external commands, and maybe also as part
> of a pipe.

I also don't remember the reason, why remote file name completion was
discarded for external command's arguments and pipes. Performance?

If this is what users want, we should get rid of this restriction.

Best regards, Michael.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79151 <at> debbugs.gnu.org, Jim Porter <jporterbugs <at> gmail.com>
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Mon, 04 Aug 2025 11:37:53 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
> Hi Daniel & Jim,
>
>>     ;; Determine, whether remote file names shall be completed.  They
>>     ;; shouldn't for external commands, or when in a pipe.  Respect
>>     ;; also `eshell-cmpl-remote-file-ignore', which could be set by
>>     ;; the user.
>>
>> I often want to complete file names in when I am executing a command in
>> a remote directory, also for external commands, and maybe also as part
>> of a pipe.
>
> I also don't remember the reason, why remote file name completion was
> discarded for external command's arguments and pipes. Performance?
>
> If this is what users want, we should get rid of this restriction.

As I understand bug#65356 the problem was that file completion sets in
in unwanted cases. Back then you pushed the 'pcomplete-remote-file-ignore'
workaround with this comment:

    Let's just go with the change to add 'pcomplete-remote-file-ignore' for 
    now. I'll have to think more about how Eshell can selectively ignore 
    remote files correctly in all cases; there are a bunch of areas where 
    Eshell could be smarter about completion already, and I have the feeling 
    they'll conflict with each other if we don't plan this out carefully...

But unfortunately this breaks useful behavior in many more cases which I
care about more than occasional false completions. For me one of the
selling points of Eshell is that I can seamlessly browse around on
remote hosts via cd. But then file name completion refuses to work.

> Best regards, Michael.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79151 <at> debbugs.gnu.org, Jim Porter <jporterbugs <at> gmail.com>
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Mon, 04 Aug 2025 11:43:50 +0200

Daniel Mendler <mail <at> daniel-mendler.de> writes:

Hi Daniel,

>> I also don't remember the reason, why remote file name completion was
>> discarded for external command's arguments and pipes. Performance?
>>
>> If this is what users want, we should get rid of this restriction.
>
> As I understand bug#65356 the problem was that file completion sets in
> in unwanted cases. Back then you pushed the 'pcomplete-remote-file-ignore'
> workaround with this comment:

pcomplete-remote-file-ignore is important in the shell-mode case. We
don't want 'cd /sudo::/' commands there :-)

>     Let's just go with the change to add 'pcomplete-remote-file-ignore' for 
>     now. I'll have to think more about how Eshell can selectively ignore 
>     remote files correctly in all cases; there are a bunch of areas where 
>     Eshell could be smarter about completion already, and I have the feeling 
>     they'll conflict with each other if we don't plan this out carefully...

IIRC, this comment was from Jim. I have no personal preference, how
Eshell allows or discards remote file name completion.

Best regards, Michael.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79151 <at> debbugs.gnu.org, Jim Porter <jporterbugs <at> gmail.com>
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Mon, 04 Aug 2025 11:55:59 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
> Hi Daniel,
>
>>> I also don't remember the reason, why remote file name completion was
>>> discarded for external command's arguments and pipes. Performance?
>>>
>>> If this is what users want, we should get rid of this restriction.
>>
>> As I understand bug#65356 the problem was that file completion sets in
>> in unwanted cases. Back then you pushed the 'pcomplete-remote-file-ignore'
>> workaround with this comment:
>
> pcomplete-remote-file-ignore is important in the shell-mode case. We
> don't want 'cd /sudo::/' commands there :-)

Yes, in shell-mode the variable pcomplete-remote-file-ignore is set to
t, such that remote completion is disabled completely, which is probably
the right thing to do.

>>     Let's just go with the change to add 'pcomplete-remote-file-ignore' for 
>>     now. I'll have to think more about how Eshell can selectively ignore 
>>     remote files correctly in all cases; there are a bunch of areas where 
>>     Eshell could be smarter about completion already, and I have the feeling 
>>     they'll conflict with each other if we don't plan this out carefully...
>
> IIRC, this comment was from Jim. I have no personal preference, how
> Eshell allows or discards remote file name completion.
>
> Best regards, Michael.

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>,
 Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79151 <at> debbugs.gnu.org
Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments
 with tramp
Date: Thu, 7 Aug 2025 11:21:35 -0700

On 8/4/2025 2:37 AM, Daniel Mendler via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> As I understand bug#65356 the problem was that file completion sets in
> in unwanted cases. Back then you pushed the 'pcomplete-remote-file-ignore'
> workaround with this comment:
> 
>      Let's just go with the change to add 'pcomplete-remote-file-ignore' for
>      now. I'll have to think more about how Eshell can selectively ignore
>      remote files correctly in all cases; there are a bunch of areas where
>      Eshell could be smarter about completion already, and I have the feeling
>      they'll conflict with each other if we don't plan this out carefully...
> 
> But unfortunately this breaks useful behavior in many more cases which I
> care about more than occasional false completions. For me one of the
> selling points of Eshell is that I can seamlessly browse around on
> remote hosts via cd. But then file name completion refuses to work.

I think the issue there was that we were trying to avoid passing Tramp 
absolute file names to external commands (which don't understand Tramp 
syntax).

This area is frankly a bit convoluted, since these two commands produce 
completely different results:

  $ cd /ssh:somehost:~

  $ cat /home/user/somefile.txt
  $ *cat /home/user/somefile.txt

The first "cat" runs 'eshell/cat', which prints the contents of the file 
on the local host, but the second runs "/usr/bin/cat" on somehost, 
printing the contents of the file on that remote host.

Fixing that issue would make it easier to define proper semantics for 
how remote file name completion works. I have a patch for this, though I 
abandoned it since it wasn't a very good way to do things, and haven't 
gotten far on a better implementation (though I have some notes 
somewhere about what that implementation would look like).

That said, maybe we could come up with a stopgap solution for completion 
in the meantime...

Previous Next

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