Daniel Mendler <mail@daniel-mendler.de> writes:


take a look at epc --- > 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
>

-- 

Thanks,

--Raman
♈ Id: kg:/m/0285kf1  🦮