GNU bug report logs - #26591
26.0.50; Using local emacs+tramp with remote emacsclient

Previous Next

Full log

View this message in rfc822 format

From: peder <at> news.klingenberg.no (Peder O. Klingenberg)
To: 26591 <at> debbugs.gnu.org
Subject: bug#26591: 26.0.50; Using local emacs+tramp with remote emacsclient
Date: Fri, 28 Apr 2017 13:29:19 +0200

On Fri, Apr 28 2017 at 12:42, Eli Zaretskii wrote:

> Also, I don't see "/home" used anywhere in the example, so something
> is missing here.

The shared file system is just the easiest way for emacs and emacsclient
to both see the same server file, containing port number and security
cookie.  The default placement of that file is in ~/.emacs.d/server, and
a shared /home makes sure it's reachable from both server and client.

I can see how that would be unclear.  I'll improve it, and fix the other
things you pointed out.

> Why the test for argv[i] being an absolute file name?  And if relative
> file names cannot be supported, I think emacsclient should emit an
> error message rather than silently ignoring --tramp.

The previous hunk of the patch adds the tramp prefix to the -dir
argument, which ends up setting `default-directory' for the server
buffers.  That makes relative filenames work.

With an absolute filename, if we don't prepend the tramp prefix, the
`default-directory' is ignored serverside and emacs tries to open a
local-to-emacs absolute file.  So we need to prepend the tramp
formula to tell emacs that the absolute filename is remote.

It would probably do no harm to include the tramp prefix on non-absolute
filenames as well, but it's not necessary, due to the previous -dir.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Previous Next

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