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

[sbaugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> 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.

That's all I ask for, the ability to make such small, careful, cautious
improvements.  I think with enough of these, we will get to a much
better place.  As long as every individual small improvement is not
rejected just because it is too small of an improvement...

And I have the ability to test these improvements at my site (of ~500
users with diverse configurations), so I am in a decent position to make
these small improvements without breaking Emacs.  As long as I don't
have to carry those patches forever...

> 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've stared at low-level code in Emacs a good amount, but certainly I
wouldn't claim to understand Emacs yet.  Nevertheless...

I think Lisp threads shows that this is not true.  With that as the
foundation, and making incremental small improvements to the C core to
increase the amount of stuff that can be done in Lisp threads, we can
build a new-generation Emacs incrementally within the old.  IMO the
reason we haven't done this yet because Lisp threads are still very
limited in what they can do without blocking.

But we don't have to agree - I'm happy to make small, step-by-step
improvements, which are justifiable on their own.  That's what I'm doing
now: I am trying to fix blocking issues which I get lots of user
complaints about, not change things for no reason.

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