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

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Tue, 04 Jul 2023 16:48:06 +0000 (UTC)
> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > 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.

We seem to differ in what we call "small" improvements...

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

If what I said were indeed not true, Lisp threads would have been a
hot feature, used by every package out there.  That it is not so
should teach us something.  I don't know if you tried to write a
serious application based on Lisp threads, but if not, maybe you
should try.