Calling emacsclient

[Thorsten Jolitz]

Hi List,

with one emacs-daemon (named 'emacs1') running, the following external
call to emacsclient succeeds:

,-----------------------------
| (call 'emacsclient
| "-s" "emacs1"
| "-a" ""
| "-c" "file...")
`-----------------------------

But what I really would need is a more generic version that does not use
the server-name. The manual says:

,------------------------------------------------------------------
| ‘-s server-name’
| ‘--socket-name=server-name’
|
| Connect to the Emacs server named server-name. The server name is
| given by the variable server-name on the Emacs server. If this
| option is omitted, emacsclient connects to the first server it
| finds. (This option is not supported on MS-Windows.)
`------------------------------------------------------------------

This does not work in my case. If I use

,-----------------------------
| (call 'emacsclient
| "-c" "file...")
`-----------------------------

I get:

,-----------------------------------------------------------------------
| emacsclient: can't find socket; have you started the server?
| To start the server in Emacs, type "M-x server-start".
| emacsclient: No socket or alternate editor. Please use:
|
| --socket-name
| --server-file (or environment variable EMACS_SERVER_FILE)
| --alternate-editor (or environment variable ALTERNATE_EDITOR)
`-----------------------------------------------------------------------

while

,-----------------------------
| (call 'emacsclient
| "-a" ""
| "-c" "file...")
`-----------------------------

starts a new emacs-daemon (although emacs-server 'emacs1' is running).

Question:
How do I get the behaviour described in the manual: "If this
option [-s] is omitted, emacsclient connects to the first server it
finds." ?

I would need a generic call to emacsclient that first looks for a
running server (which ever it encounters) and only starts a new daemon
if there is no server running already.

I'm on Arch Linux.

--
cheers,
Thorsten

[William Gardella]

Hi Thorsten,

Thorsten Jolitz <tjo...@googlemail.com> writes:
> Question:
> How do I get the behaviour described in the manual: "If this
> option [-s] is omitted, emacsclient connects to the first server it
> finds." ?

Based on my own experience, that passage you quoted from (info "(emacs)
emacsclient Options") is just plain incorrect. Emacsclient run without
-s simply expects the server to be named the default server name,
`server'. It fails if it can't find this server, or fails over to
starting up emacs --daemon if run with -a "" or an ALTERNATE_EDITOR=""
environment. The emacsclient manpage, btw, holds out no such hope that
the "first server it finds" thing referenced in the Info manual will
work.

I'm writing up a bug report against the Info manual.

One possibility would be to use the emacsclient -s option together with
a shell wildcard, e.g.:

emacsclient -c -s /tmp/emacs1000/*

works, whatever the name of the socket inside /tmp/emacs1000/ is. So
you could use that trick with the value of your `server-socket-dir'
variable. If you're going to often have multiple emacs daemons, you
should probably give them persistent names based on their role.

Best,
WGG
--
I use grml (http://grml.org/)

[Thorsten Jolitz]

William Gardella <garde...@gmail.com> writes:

Hi William,

> Thorsten Jolitz <tjo...@googlemail.com> writes:
>> Question:
>> How do I get the behaviour described in the manual: "If this
>> option [-s] is omitted, emacsclient connects to the first server it
>> finds." ?
>
> Based on my own experience, that passage you quoted from (info "(emacs)
> emacsclient Options") is just plain incorrect.

I tried it before, and I tried it recently - it definitely doesn't work

> Emacsclient run without -s simply expects the server to be named the
> default server name, `server'.

Thats already a simple solution for my problem. So I can call
emacsclient generically without the '-s' option in my program and tell
my users that the emacs-daemon they want to connect to must be started
with server-name 'server'.

> One possibility would be to use the emacsclient -s option together with
> a shell wildcard, e.g.:
>
> emacsclient -c -s /tmp/emacs1000/*
>
> works, whatever the name of the socket inside /tmp/emacs1000/ is. So
> you could use that trick with the value of your `server-socket-dir'
> variable.

I have the same 'server-socket-dir', so hardcoding this works fine on my
machine. But what if I need a generic version? Can I get the value of
`server-socket-dir' and use it for the '-s' option in the same external
call to emacsclient? Or would I need two consecutive calls to
emacsclient, the first one reading the value of `server-socket-dir' via
'emacsclient -e "(...some lisp...)"', the second one using it for the
'-s' option from a variable of the calling program?

Anyway, supposing that the adressed emacs-server is called 'server' is
probably the simplest and best solution. Thanks for your help.

--
cheers,
Thorsten

[Suvayu Ali]

On Mon, Nov 12, 2012 at 02:04:31PM +0100, Thorsten Jolitz wrote:
> William Gardella <garde...@gmail.com> writes:
>
> > One possibility would be to use the emacsclient -s option together with
> > a shell wildcard, e.g.:
> >
> > emacsclient -c -s /tmp/emacs1000/*
> >
> > works, whatever the name of the socket inside /tmp/emacs1000/ is. So
> > you could use that trick with the value of your `server-socket-dir'
> > variable.
>

> I have the same 'server-socket-dir', so hardcoding this works fine on my
> machine. But what if I need a generic version? Can I get the value of
> `server-socket-dir' and use it for the '-s' option in the same external
> call to emacsclient? Or would I need two consecutive calls to
> emacsclient, the first one reading the value of `server-socket-dir' via
> 'emacsclient -e "(...some lisp...)"', the second one using it for the
> '-s' option from a variable of the calling program?

I believe a more generic server-socket-dir is /tmp/emacs${UID}/.

--
Suvayu

Open source is the future. It sets us free.

[Thorsten Jolitz]

Suvayu Ali <fatkasuv...@gmail.com> writes:

> On Mon, Nov 12, 2012 at 02:04:31PM +0100, Thorsten Jolitz wrote:
>> William Gardella <garde...@gmail.com> writes:
>>

>> > One possibility would be to use the emacsclient -s option together with
>> > a shell wildcard, e.g.:
>> >
>> > emacsclient -c -s /tmp/emacs1000/*
>> >
>> > works, whatever the name of the socket inside /tmp/emacs1000/ is. So
>> > you could use that trick with the value of your `server-socket-dir'
>> > variable.
>>

>> I have the same 'server-socket-dir', so hardcoding this works fine on my
>> machine. But what if I need a generic version? Can I get the value of
>> `server-socket-dir' and use it for the '-s' option in the same external
>> call to emacsclient? Or would I need two consecutive calls to
>> emacsclient, the first one reading the value of `server-socket-dir' via
>> 'emacsclient -e "(...some lisp...)"', the second one using it for the
>> '-s' option from a variable of the calling program?
>
> I believe a more generic server-socket-dir is /tmp/emacs${UID}/.

if the /tmp/emacs part is more or less constant for all kinds of
GNU/Linux distributions this would be even more generic than relying on
the server-name 'server'. Thanks for the tip.

--
cheers,
Thorsten

[Thorsten Jolitz]

William Gardella <garde...@gmail.com> writes:

> Thorsten Jolitz <tjo...@googlemail.com> writes:
>> Question:
>> How do I get the behaviour described in the manual: "If this
>> option [-s] is omitted, emacsclient connects to the first server it
>> finds." ?
>
> Based on my own experience, that passage you quoted from (info "(emacs)
> emacsclient Options") is just plain incorrect. Emacsclient run without
> -s simply expects the server to be named the default server name,
> `server'. It fails if it can't find this server, or fails over to
> starting up emacs --daemon if run with -a "" or an ALTERNATE_EDITOR=""
> environment. The emacsclient manpage, btw, holds out no such hope that
> the "first server it finds" thing referenced in the Info manual will
> work.
>
> I'm writing up a bug report against the Info manual.

After some experimenting it seems to me that there is another bug, at
least in my case

,---------------------------
| (call 'emacsclient
| "-e"
| "(message \"CALL 1\")")
`---------------------------

does not work, while

,---------------------------
| (call 'emacsclient
| "--eval"
| "(message \"CALL 1\")")
`---------------------------

does (on Archlinux).


I have another problem not yet solved - I want to call an Emacsclient
with a file to open and some code to evaluate. Using the "-c" and
"--eval" options in one call gives an error for me, and this seems to be
in accordance with the manual that says its either the one or the other.

However, if I try two sequential calls instead, it works somehow, but
not as intended. These two calls directly after another

,--------------------------
| (call 'emacsclient
| "-c" "my/dir/my-file")
`--------------------------

,---------------------------
| (call 'emacsclient
| "--eval"
| "(message \"CALL 1\")")
`---------------------------

open a new emacs-frame showing a 'my-file' buffer, but in the *Messages*
buffer there is no CALL 1 message. But when I kill the Emacsclient-frame
with C-x C-c, CALL 1 is shown as return value in the calling external
program and now appears in the *Messages* buffer too. It seems the
second call is waiting for the first call to terminate.

Now I wonder how I can call Emacsclient with a file I want to edit, but
make it (immediately) evaluate some code when it starts up? Is that
possible in the call(s) itself, or do I have to use hooks or something
like that?

--
cheers,
Thorsten

[William Gardella]

Hi.

Thorsten Jolitz <tjo...@googlemail.com> writes:
> After some experimenting it seems to me that there is another bug, at
> least in my case
>
> ,---------------------------
> | (call 'emacsclient
> | "-e"
> | "(message \"CALL 1\")")
> `---------------------------
>
> does not work, while
>
> ,---------------------------
> | (call 'emacsclient
> | "--eval"
> | "(message \"CALL 1\")")
> `---------------------------
>
> does (on Archlinux).

This one I cannot reproduce. What is your emacs version?

> Now I wonder how I can call Emacsclient with a file I want to edit, but
> make it (immediately) evaluate some code when it starts up? Is that
> possible in the call(s) itself, or do I have to use hooks or something
> like that?

Depending on what this code is, you may be able to do it with a
file-local variable or a hook. Or you could have emacsclient call
something like

(progn
(set-buffer (find-file "~/somecode.c"))
(some-nifty-code-here))

Hope this helps,

[William Gardella]

Hi again, I had some further notes/thoughts for clarification.

Thorsten Jolitz <tjo...@googlemail.com> writes:

> I have another problem not yet solved - I want to call an Emacsclient
> with a file to open and some code to evaluate. Using the "-c" and
> "--eval" options in one call gives an error for me, and this seems to be
> in accordance with the manual that says its either the one or the other.
>
> However, if I try two sequential calls instead, it works somehow, but
> not as intended. These two calls directly after another
>
> ,--------------------------
> | (call 'emacsclient
> | "-c" "my/dir/my-file")
> `--------------------------
>
> ,---------------------------
> | (call 'emacsclient
> | "--eval"
> | "(message \"CALL 1\")")
> `---------------------------
>
> open a new emacs-frame showing a 'my-file' buffer, but in the *Messages*
> buffer there is no CALL 1 message. But when I kill the Emacsclient-frame
> with C-x C-c, CALL 1 is shown as return value in the calling external
> program and now appears in the *Messages* buffer too. It seems the
> second call is waiting for the first call to terminate.

This is actually expected behavior, by the way. In an interactive emacs
environment such as an emacsclient frame, `standard-output' is the
*Messages* buffer. In a batch arrangement, such as emacsclient --eval,
`standard-output' is the calling shell or program's standard output. So
I'm guessing that your second call actually completes normally, but you
don't see it until you close the frame.

There is a syntax for using --eval inside an existing interactive
emacsclient frame. One cannot combine -t and -e. Try emacsclient -te
'(message "boop") and check your *Messages* buffer.

What is the Lisp-like program composing these calls, by the way? Is
this scsh or something?

-WGG

[William Gardella]

William Gardella <garde...@gmail.com> writes:

> There is a syntax for using --eval inside an existing interactive
> emacsclient frame. One cannot combine -t and -e. Try emacsclient -te
> '(message "boop") and check your *Messages* buffer.

By "cannot," I meant "can." Sorry for the noise. :)

[Thorsten Jolitz]

William Gardella <garde...@gmail.com> writes:

Hi William,

thanks a lot for you help.

Maybe its related to this too:

,------------------------------------------------------
| Apparently there is a problem with running C programs
| that use stdout under Emacs: stdout is attached to a
| pipe, which is a block device, rather than the
| console, which is a character device. Thus, you don't
| get your output until the program terminates or there
| is enough data to fill the block buffer.
`------------------------------------------------------
from: http://lua-users.org/lists/lua-l/2007-04/msg00642.html

> There is a syntax for using --eval inside an existing interactive
> emacsclient frame. One cannot combine -t and -e. Try emacsclient -te
> '(message "boop") and check your *Messages* buffer.

I tried that, but the bahaviour of "-e" and "-te" is exactly the same -
output appears only after the frame is closed.

> What is the Lisp-like program composing these calls, by the way? Is
> this scsh or something?

Its PicoLisp:
http://picolisp.com/5000/!wiki?home
here is the doc for call:
http://software-lab.de/doc/refC.html#call

PicoLisp has a command-line modeled after Vi (modal editing), and I'm
writing an Emacs mode for that command-line. That does not only include
using Emacs keybindings for editing and navigation on the command-line,
but also calling an editor (Vi or Emacs) for editing symbols or PicoLisp
source-files.

So the PicoLisp philosophy is a bit upside down - you work on the
command-line and call an editor when you need one (and close it when
done), instead of living inside the editor and controlling external
programs via Emacs subprocesses. Emacsclient is the perfect solution for
this 'open an editor on demand' philosphy.

There is a PicoLisp major mode (picolisp.el) for Emacs and a comint based
inferior-picolisp.el (and even a swank/slime implementation) that can be
used the usal way - opening a .l (PicoLisp source) file puts it in
PicoLisp-mode, and a call to 'run-picolip' starts a PicoLisp process
in a dedicated process-buffer from inside Emacs. Then, code in the
source buffer can be evaluated and send to the process buffer.

What I'm struggling with is that in my use case, PicoLisp calls Emacs
not vice versa. So there is an open connection between both programs,
probably based on stdin/out, and I would like to use it to do the usual
things like

,------------------------------------------------
| C-x C-e picolisp-send-last-sexp
| C-c C-e picolisp-send-definition
| C-c C-l picolisp-load-file
| C-c C-r picolisp-send-region
| C-c C-x switch-to-picolisp
| C-c M-e picolisp-send-definition-and-go
| C-c M-r picolisp-send-region-and-go
`------------------------------------------------

but not sending from the source-code buffer in the emacsclient to a
process-buffer, but rather sending from the Emacs source-code buffer to the
PicoLisp command-line shell, i.e. via stdout back to the calling program ...

... that sits there after calling emacsclient (inside the 'em' function)
,---------------------
| : (em 'edit)
| Waiting for Emacs...
`---------------------

So I - probably - would need to
1. change stdout from *Messages* to regular stdout
2. flush output immediately after written
3. make output appear in the PicoLisp shell

Or maybe I should rather use the existing connection and open an Emacs
process-buffer for it - but how do I get a process-object for it?

--
cheers,
Thorsten

[Thorsten Jolitz]

William Gardella <garde...@gmail.com> writes:

> Thorsten Jolitz <tjo...@googlemail.com> writes:
>> After some experimenting it seems to me that there is another bug, at
>> least in my case
>>
>> ,---------------------------
>> | (call 'emacsclient
>> | "-e"
>> | "(message \"CALL 1\")")
>> `---------------------------
>>
>> does not work, while
>>
>> ,---------------------------
>> | (call 'emacsclient
>> | "--eval"
>> | "(message \"CALL 1\")")
>> `---------------------------
>>
>> does (on Archlinux).
>
> This one I cannot reproduce. What is your emacs version?

GNU Emacs 24.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10) of
2012-02-07 on arch

But, stangely enough, now it works here too. Sorry for the noise.

>> Now I wonder how I can call Emacsclient with a file I want to edit, but
>> make it (immediately) evaluate some code when it starts up? Is that
>> possible in the call(s) itself, or do I have to use hooks or something
>> like that?
>
> Depending on what this code is, you may be able to do it with a
> file-local variable or a hook. Or you could have emacsclient call
> something like
>
> (progn
> (set-buffer (find-file "~/somecode.c"))
> (some-nifty-code-here))