Re: emacsclient in elisp

[Daniel Mendler]

On 5/21/21 8:16 AM, Eli Zaretskii wrote:
>> 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.

Of course, but IO-bound waiting is fundamentally different from
CPU-bound computations.

>> 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.

You are right about that. I think Stefan should elaborate. What I am
doing now - I am "upgrading" the emacsclient protocol on the server by
replacing the `server-process` filter with my own version. This works
well and is also clean. I am actually never using the emacsclient
protocol now, I am only reusing the Emacs infrastructure to set up the
server and to daemonize.

>> (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.

There is a point in doing what I am doing but it strongly depends on the
UI you are using. Do you know the command line fuzzy finder fzf. My
program basically emulates that working mode in Emacs. The grep
functionality offered by Emacs is not related to that, but is fine by
itself. There is no "need" for my package, it is just an experiment to
see if I can retrofit certain interaction models onto Emacs.

Daniel