Re: emacsclient in elisp

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Sat, 22 May 2021 13:49:20 +0200
> 
> >>> For my use case this would not be harsh. A running Emacs will explicitly
> >>> opt-in to use the special make-stdio-process to read from stdin. This
> >>> special process will only be used by external worker Emacsen controlled
> >>> from the main Emacs. In that scenario the data flowing over stdin-stdout
> >>> is tightly controlled (IPC protocol). There hopefully won't be spurious
> >>> read-from-minibuffer calls.
> >>
> >> The last assumption is questionable
> > 
> > I mean in general, not for the single use case you described.
> 
> I agree that it is questionable in general. However given that the use
> of `make-stdio-process` is opt-in, the change in behavior would not be
> severe.

No one said that by opting-in to this behavior a Lisp program gives up
the ability to ask user questions via the minibuffer.  I can easily
imagine programs that would like to do both.

> One could also keep the current behavior of `read-from-minibuffer`
> as is, even if `make-stdio-process` is used.

??? How do you know which stdin input should go one way and which
should go the other way?

> The question is if that would shadow some bugs, since you probably
> don't want to use both of them at the same time.

What do you mean by "at the same time"?  If I have a stdin-process
active, we watch it via pselect and read from it using the machinery
in wait_reading_process_output and accept-process-output.  During all
the time such a process is active, I see no way to also read from the
same descriptor bypassing the above mechanisms, in a way that won't
cause trouble on the Lisp level, due toe the basic inability to decide
which input should go what way.