Re: emacsclient in elisp

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca, bugs@gnu.support, emacs-devel@gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Thu, 20 May 2021 22:54:45 +0200
> 
> On 5/20/21 9:45 PM, Eli Zaretskii wrote:
> > But then I don't understand the importance of stdin in this context.
> > If you want to read output from another program, just run that
> > program, in this case another Emacs, as a subprocess.  Then anything
> > that other program writes to its stdout will be read as part of normal
> > machinery of reading sub-process output, including filters, sentinels,
> > and all that.
> 
> Yes, that's right. I have two Emacs processes A and B. The process A
> starts process B as subprocess and communicates with it via the pipe.
> The process B reads from the stdin using `(read t)` or
> `(read-from-minibuffer..)`. Now process B starts another subprocess C,
> which has a filter and a sentinel. While B reads from stdin, B hangs and
> the C-filter is not executed.

The same will happen if B runs some Lisp function that takes a long
time.

> Alternatively one can use network streams. A creates a server, B creates
> a client and then they communicate asynchronously, B can start a
> subprocess C and the AB-network communication does not impede the
> subprocess C.

So you already have a solution for such use cases, right?  Then what
would be the advantage of doing the same via stdin?

> I would like to offload work from Emacs to sub-Emacs processes which are
> connected via some IPC protocol. I am currently using the emacsclient
> protocol for this (with some custom extensions). Stefan suggested that
> it may be better if the Emacs processes communicate directly using
> pipes. But given the stdin blocking problem, described above, this is
> not possible.

Then I guess it is Stefan who should answer the question above.

> Actually I am happy with using the emacsclient protocol now. It is a bit
> of a hack, but it works for the simple use case I am currently exploring

I don't see why it would be considered a hack.  Using the emacsclient
_protocol_ might be considered a kludge, but you can use your own
protocol, and then I see no kludge at all in this design.

> (https://github.com/minad/affe). There I have Emacs A (frontend)
> starting an Emacs B (backend) which starts grep as a subprocess C,
> generating output. Then A sends filter regular expressions to B, B
> filters the output of C and answers with the matches.

Not sure why you need Grep in this equation at all: Emacs is perfectly
capable of searching files entirely on its own, and since your design
is asynchronous, speed should not matter too much anyway.