Re: emacsclient horribly broken

[Tim Van Holder]

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 
> is
> > 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 
> arguments.
>
> 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 :-)