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

Previous Next

Full log

View this message in rfc822 format

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: bug#29889: 27.0.50; Slow visual selection
Date: Fri, 20 May 2022 16:18:31 +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 20:39:43 +0800
> 
> > 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.)

What if the buffer is killed?

Anyway, if other applications behave like that, 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.