Re: emacsclient in elisp

[Daniel Mendler]

On 5/19/21 3:41 PM, Stefan Monnier wrote:
> No.  I think the reason goes as follows: for the intended purpose of
> `emacsclient`, the time needed to start Emacs itself makes an ELisp
> implementation useless...

Of course.

> and for other purposes you can generally have
> a separate server process per client process and it's just as easy if
> not easier to then use `start-process` and a ad-hoc communication
> protocol...

When I a start an Emacs process in the background, which IPC protocol do
you recommend to communicate with it? Should I start a separate custom
TCP server on the daemon and then communicate with it using a TCP client
(inventing my own protocol and with the implied security issues)?

I cannot start the Emacs in the background and communicate with it by
sending/receiving data via stdin/stdout, since Emacs does not offer an
asynchronous facility to read from stdin. Asynchronous reading would be
needed on the daemon. If I am calling `read-from-minibuffer` there it
reads from stdin but blocks the process. Is this correct?

For my use case it is necessary that I start an Emacs process in the
background, which stays alive for some time, maintaining some state.
Then this process should be controlled asynchronously.

There exists the async package, which starts a new Emacs process per
future if I understood correctly. This is not sufficient for what I am
trying.

> rather than having to reuse the protocol used for `emacsclient`
> (which is neither very convenient nor very extensible).

I am not sure I agree. I can send sexps and return sexps which I
consider a sufficiently extensible protocol. But from what I've seen the
client is buggy - it is for example not possible to send strings
containing \0 bytes.

Daniel