bug#63865: 29.0.90; call-process while owning the X selection hangs other processes

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Spencer Baugh <sbaugh@janestreet.com> writes:

> "Emacs can not respond to selection requests when it is not reading
> keyboard input." sounds like a bug to me!  Even if it's hard to fix,
> it's still a bug.
>
> If I'm implementing some package and I decide to use call-process for
> some long operation, then some user uses my package and it runs
> call-process, and they get bored while waiting and switch away from
> Emacs, they'll experience a hang in some other application.  That hang
> seems clearly undesirable!
>
> (I should mention that Slack (and possibly all Electron applications)
> have worse behavior than I originally said: They don't just hang on
> paste, their UI hangs completely while Emacs is in call-process.  (I
> guess these applications are constantly requesting the selection or
> something?)  Which is an extremely bad experience for the users of
> packages which use call-process...)
>
> I'm personally working around this by replacing call-process with
> start-process and accept-process-output.  Because otherwise my packages
> (and any other package using call-process ever) will cause random hangs
> in other applications, which is obviously bad and not something anyone
> would want.
>
> So perhaps call-process on Unix should be reimplemented in terms of
> those functions?  Or if that would change behavior too much, perhaps
> call-process should be deprecated in favor of some new helper built on
> those?

Do you expect completely arbitrary Lisp code (which may perform _any_
operations, including reading user input) to run inside call-process?
Because Emacs runs such code upon receiving a selection request.

Hangs in badly implemented programs are a small price to pay for such
flexibility.  Try getting a clipboard manager: it may resolve the issue.