bug#70792: 30.0.50; [PATCH] Add Eshell support for expanding absolute file names within the current remote connection

[Jim Porter]

On 5/8/2024 6:20 AM, Eli Zaretskii wrote:
> I think "/:" quoting should not change the host of the file name.
> That's because the user might need this quoting for file names on the
> remote host.

Not to say we *should* do this, but if we kept the "/:" syntax of my 
patch, a user could still /:-quote a remote file name in Eshell by using 
the fully-qualified name like: "/ssh:user@remote:/:/blah".

I can construct an argument for why using /: this way in Eshell would 
make sense, but maybe it's just needlessly "clever"...

(As a note, Eshell already uses /:-quoting to mean "on the local host" 
in one spot: for the command to run. However, I added that for Emacs 30, 
so we can still change it without worrying about compatibility issues. 
See the manual here for more info: 
<https://git.savannah.gnu.org/cgit/emacs.git/tree/doc/misc/eshell.texi#n1534>.)

> If the user wants to specify a local file name while default-directory
> is remote, the user can use the normal Tramp "/METHOD:..." notation.

How about a new "local" method? Then users would type 
"/local::~/some-file.txt". That's more typing, but it's also more clear, 
and doesn't repurpose an existing syntax used elsewhere in Emacs.

I don't think the extra typing is *too* bad, since cross-host file names 
are probably a lot rarer than regular intra-host ones. Most likely, 
users will use cross-host file names primarily when cd'ing to a 
different host.

If I go this route, I'm not sure whether it would be better to make 
"local" a real file name handler available everywhere in Emacs despite 
only being useful for Eshell, or if Eshell should just strip out the 
"/local::" prefix before sending it to other parts of Emacs. I'm leaning 
towards the former though, since the latter seems like a hack that could 
have unforeseen consequences.