bug#29889: 27.0.50; Slow visual selection

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: larsi@gnus.org,  m.sujith@gmail.com,  29889@debbugs.gnu.org
> Date: Fri, 20 May 2022 19:51:17 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe we need yet another value for that variable, which would set the
> > selection not only for shift-selection?
> 
> I guess so.  How about a number indicating the maximum amount of
> characters to put into the primary selection, which will not happen if
> the region exceeds that many characters in length?

That's bad UX, IMO: chances are you don't know that only part of the
text was put in the selection.  Or do you suggest displaying a warning
when text in the selection is truncated?

How do other apps handle request to put huge chunks of text into the
primary selection?  If they honor such requests seamlessly and without
slowing down the response, why cannot Emacs do the same?