Re: call-process should not block process filters from running

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: sbaugh@catern.com
>> Date: Mon, 03 Jul 2023 13:53:02 -0400
>> 
>> > I don't recommend doing either from call_process: a lot of existing
>> > code relies on Lisp code not running inside calls to that function,
>> > and errors inside selection handlers will be signaled even if
>> > nothing's wrong with the process being called.
>> 
>> Right, in the real patch this will be behind a new variable which code
>> can let-bind to explicitly opt-in to the new behavior, as Eli suggested.
>> So existing code won't see behavior changes.
>
> I'm not sure the new code should call swallow_events, even if
> protected by some variable.  We will be giving people a too-long rope
> to hang themselves.  It is unreasonable to assume Lisp programmers
> will be able to decide when to allow this and when not to, given the
> complexities.

What is complex about this?  What problems can it cause that aren't
already covered by "arbitrary Lisp will run during call-process"?

If swallow_events is too general, I can just call only
process_special_events if necessary.

AFAIK this is a pretty small change, all it changes is letting Emacs
handle X selection requests while in call-process.  (i.e. letting other
X clients paste when Emacs owns the selection)

> Why do we need to jump through all the hoops right at the beginning?
> Why not make a small step forward and see if this experiment is more
> useful than it is dangerous?  Then we could decide whether to make the
> next step, and how.  No one said that pasting into Emacs while a
> subprocess runs is the most important capability to enable.  I'd first
> make sure the user can type at the keyboard without adverse effects.

It's not pasting into Emacs, it's pasting into other X clients.  I
indeed don't care about pasting into Emacs while a subprocess runs.  But
I like to be able to use other X clients, including by pasting, while a
subprocess runs.

This is not about allowing the user to type at the keyboard while
call-process runs - that's a much bigger change for sure!

> Let's not over-engineer this without a sufficient justification.

I've received lots of user complaints about the inability to paste in
other X clients while Emacs is sitting in call-process.  Fixing that is
one of my key motivations for this change.

>> > Also, you should at least check that call_process is reentrant: it
>> > must be able to handle calls to itself made by any timers or selection
>> > handlers that run within the process input loop, with the processes
>> > being called completing in any order.
>> 
>> Hm, good point.  Right now in call_process there's:
>> 
>>   if (synch_process_pid)
>>     error ("call-process invoked recursively");
>> 
>> So it's at least "safe" to call recursively, since it explicitly errors
>> rather than having undefined behavior.  But erroring in this way is
>> probably not desirable.
>> 
>> I can make it re-entrant.  synch_process_pid is itself a global, so
>> that's the place to start.
>> 
>> Eli, your thoughts?  Is this more complicated than you were thinking?
>
> I don't see how it will be more complicated to have a list or array of
> PIDs instead of just one value.  This "complication" is nothing
> compared to the job of rewriting call-process with all its quirks in
> Lisp, even if you ignore the problems and loss of performance we'd
> need to sustain to decode and insert the output in Lisp rather than in
> C.

OK, sounds good.