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

Previous Next

Full log

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 20:39:43 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

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

The latter, yes.

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

Those programs only "own" the selection without copying anything.  When
another program asks for the contents of the selection, they are sent
directly from the "buffer" containing them.  (That does mean if the
buffer contents change, so will the contents of the selection.)

Previous Next

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