[Top][All Lists]

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

Re: emacsclient horribly broken

From: Tim Van Holder
Subject: Re: emacsclient horribly broken
Date: Thu, 2 Nov 2006 18:53:29 +0100

On 11/2/06, Juanma Barranquero <address@hidden> wrote:
On 11/2/06, Tim Van Holder <address@hidden> wrote:
> I removed /tmp/emacs1000 after closing emacs, and now the problem is
> gone - I only get the "address in use" error if I start a second emacs (which 
> understandable I guess, but that never happened before today).

AFAICS, if you start two Emacsen and both try to open the same local
socket, the error should be expected. You must somehow arrange for
them to have a different value of `server-name'.

Like I said, I'm not surprised by the error as such - it indeed makes sense that
two emacs instances cannot both use the same socket file.  All I'm saying
is that this is the first time I get the error (I fairly frequently
open extra emacsen,
and my GNOME panel launcher uses -f server-start). I'm not sure what emacs
did before; I assume it either figured "server already running, no problem", or
just created a new socket.

> I just expected emacsclient to use whatever emacs used without extra 

I don't see it as a big problem, because obviously setting
EMACS_SERVER_FILE to ~/.emacs.d/server/server in your .profile is
trivial. However, if you really do feel that emacsclient should
default to TCP sockets if the server-file exists, please do comment it
on the developer's list; or I'll bring the issue, if you don't usually
read the list.

> I can't think of any
> realistic situation where ~/emacs.d/server/server exists (due to emacs
> being active as server over TCP) and I'd still want emacsclient to try local
> sockets instead.

I can: having two Emacs servers around, one to connect from the local
machine (with Unix sockets) and the other for remote connections. Unix
sockets are inherently more secure (there's no sniffing around, at
least from the network); perhaps you don't want to have the same info
available in both. Remember that a simple:

  emacsclient --eval "(buffer-list)"

can reveal information, and

  emacsclient --eval "(let (kill-emacs-hook kill-emacs-functions) (kill-emacs))"

(or a more sophisticated variant) finish a session...

OK, I see - I discounted remote access because emacs saves the server info
locally anyway - I kind of assumed it would bind to the loopback
interface, which
would avoid most of the security issues anyway.

But if emacsclient then tried in sequence
- the serverfile specified on the command line
- or, if local sockets are supported, the first such connected socket (if any)
- or, if the default server file exists, the tcp socket it references
then both goals would be met - local sockets get precedence, and my TCP
setup is transparently handled as well. In addition, for remote TCP connections,
emacsclient could emit a warning "connecting to emacs running on <machine>
(port <port>), possibly requiring an extra keystroke to confirm.

In any case, I don't use emacsclient a great deal, I typically just
operate from a
single emacs instance on our development box, so I'm not exactly your core
audience :-)

reply via email to

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