[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26591: 26.0.50; Using local emacs+tramp with remote emacsclient

From: Peder O. Klingenberg
Subject: bug#26591: 26.0.50; Using local emacs+tramp with remote emacsclient
Date: Fri, 28 Apr 2017 13:29:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]