GNU bug report logs - #29889
27.0.50; Slow visual selection

Previous Next

Full log

Message #136 received at 29889 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 29889 <at> debbugs.gnu.org, larsi <at> gnus.org, m.sujith <at> gmail.com
Subject: Re: bug#29889: 27.0.50; Slow visual selection
Date: Fri, 20 May 2022 15:19:00 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: larsi <at> gnus.org,  m.sujith <at> gmail.com,  29889 <at> debbugs.gnu.org
> Date: Fri, 20 May 2022 19:51:17 +0800
> 
> Eli Zaretskii <eliz <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.