Subject: Re: bug#79151: 31.0.50; eshell does not complete filename arguments with tramp

From: Jim Porter <[email-masked]>
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...