GNU bug report logs - #2864
running emacsclient uninstalled

Previous Next

Full log

View this message in rfc822 format

From: "Alfred M. Szmidt" <ams <at> gnu.org>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: 2864 <at> debbugs.gnu.org
Subject: bug#2864: emacsclient bugs..
Date: Thu, 02 Apr 2009 16:12:17 -0400

     > There are a few problems with emacsclient in CVS, first one is that
     > one cannot run emacsclient from the build directory, you can do this
     > with emacs just fine.  But emacsclien gets confused as to where things
     > are, and you must do a `make install' to be able to use emacsclient
     > properly.

   Can you please describe what you do step by step?
   I can't reproduce it here.

emacsclient never looks in BUILD/src for emacs, so if you do:

emacs/lib-src/emacsclient -a "" -t

emacsclient will fail with:

ams <at> beryx:~$ emacs/lib-src/emacsclient -a "" -t             
emacs/lib-src/emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
emacs/lib-src/emacsclient: error starting emacs daemon
Emacs daemon should have started, trying to connect again
emacs/lib-src/emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
Error: Cannot connect even after starting the Emacs daemon

I.e. you have to have BUILD/src in your PATH, or do make instal (which
will put emacs in bindir/emacs and emacsclient looks there).


Another problem I found, but cannot reproduce anymore is that for some
odd reason emacs started looking for all the elisp files in
/usr/local.  But I have been unable to reproduce, so I think it was
just something on my side.

     > The second one is that the handling of -a/--alternative-editor
     > is problematic,
     > 
     > $ emacs/lib-src/emacsclient -a -c
     > emacs/lib-src/emacsclient: file name or argument required
     > Try `emacs/lib-src/emacsclient --help' for more information
     > 
     > According to the docstring, the argument to -a is optional, but
     > one must supply a empty string explicitly for things to work as
     > advertised.

   There was a typo in the code that made the info about the empty
   string not appear, it should be fixed now.

   The argument to -a is not optional, neither are the arguments for
   -d -f -s (which are documented in the same way as -a in --help).
   What needs to be done to make that clearer?

I think a simple note stating that it has to be the empty string would
be fine.

Previous Next

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