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

Previous Next

Package: emacs;

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

Date: Sat, 2 Aug 2025 11:00:02 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

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: 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...




This bug report was last modified 47 days ago.

Previous Next


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