[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: call-process should not block process filters from running
Date: Tue, 04 Jul 2023 14:10:57 +0300

> From: sbaugh@catern.com
> Date: Mon, 03 Jul 2023 16:28:25 -0400
> Eli Zaretskii <eliz@gnu.org> writes:
> > 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?

Whatever caused you to be surprised that just calling
wait_reading_process_output doesn't process selection requests.  How
many Lisp programmers understand what is going on in Emacs when such a
request is processed, and what that means for their Lisp programs?

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

Processing selection requests does not really qualify as "running
arbitrary Lisp".  It is much more subtle, and I'm quite sure the
mental model of that which most Emacs users have is very simplistic.

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

They are both potentially dangerous.

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

Famous last words ;-)

There are no "small changes" in Emacs on this level.

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

Still not important enough, IMO, for us to have to solve this right
away, since you will have the same issue when Emacs is busy with
something else, like redrawing the display or even executing some
long-running Lisp program.

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

Nothing's wrong with fixing this step by step, from where I stand.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]