bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections

[Eli Zaretskii <eliz@gnu.org>]

> Cc: Spencer Baugh <sbaugh@janestreet.com>, 64423@debbugs.gnu.org
> From: sbaugh@catern.com
> Date: Tue, 04 Jul 2023 14:46:36 +0000 (UTC)
> 
> IMO the major issue with the Emacs UI at the moment is that it blocks
> too much, relative to "modern" applications.

That is true, but it cannot be fixed by small half-measures.  The
basic Emacs design _assumes_ this single-threaded operation, and many
of the low-level parts will simply break if the assumption becomes
false.  Some will break visibly and loudly, some will break subtly and
silently, but they _will_ break.  We have seen this many times: the
seemingly-confusing code which does things no one completely
understands turns out to do all that for good reasons, which only
become visible when we in our arrogance boldly make changes no one
imagined when this was designed and implemented.  And people who
designed and implemented it, and improved it over the years, were and
are very clever, and knew what they were doing and why.

The _only_ sane way of getting a non-blocking Emacs is to redesign all
of Emacs around that idea.

> Some of this blocking can
> only be fixed by speeding up Lisp execution, but substantial parts of
> this blocking can only be fixed by making Emacs more concurrent - that
> is, making it possible for Lisp code to run concurrently with other Lisp
> code, on an opt-in basis, instead of blocking all Lisp execution while
> operations like gui-get-selection and call-process are running.

You cannot "make Emacs more concurrent", not by and large.  We can
make small improvements here and there, if we tread cautiously and do
careful damage control after each such change, but that's all.  If you
look at the low-level code in Emacs and take time to understand how it
works, you will agree with me.  (And if you don't agree, we will have
this very argument again many times in the future.)  We should accept
that fact, and either live with it or start a new-generation Emacs,
based on very different designs.  Anything else is just lying to
ourselves.

> I am aware this is a major undertaking, but I think it's important for
> Emacs to compare favorably with "modern" applications which don't
> exhibit as much random UI blocking.  I regard this as basically
> equivalent to the lexical-binding transition.

Ha!  Lexical-binding transition is nothing near what you propose.  It
changed the language and its interpreter, but not the editor and its
infrastructure and primitives.  What you suggest is several orders of
magnitude harder (read: impossible).