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 2 days ago.

Previous Next


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