bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#6774: Cut and paste with C-w/mouse-2 not working?


From: David De La Harpe Golden
Subject: bug#6774: Cut and paste with C-w/mouse-2 not working?
Date: Fri, 06 Aug 2010 21:17:53 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5

On 06/08/10 11:50, Eli Zaretskii wrote:
From: Stefan Monnier<monnier@iro.umontreal.ca>
Cc: David De La Harpe Golden<david@harpegolden.net>,  cyd@stupidchicken.com,  
6774@debbugs.gnu.org,  angelo.graziosi@alice.it
Date: Fri, 06 Aug 2010 11:13:50 +0200

But that would mean setting the selection each time the user does a
C-w or M-w or any other action that pushes text on the kill ring,
won't it?

Isn't that what Emacs has been doing for the last 10 years?

Not as far as I know.  Maybe I was living in some pipe dream, but I
always thought the actual copying happened only when some other
application actually requests the selection.

I was talking about a second level of intra-emacs laziness that exists in the present select-active-regions implementation, not inter-application stuff.

See, on X11 you can x-set-selection the _emacs-level_ selection (stored internally on selection_alist) to a non-string value that merely references a buffer, so that when/if another application requests the selection, it is looked up all the way back to a buffer (or cons of markers). The current select-active-regions implementation works that way, and thereby avoids an emacs-internal string copy sometimes (in cases like C-w/M-w that internal copy happens anyway).

My proposal was to consider that a premature optimization, go back to basics, then re-optimise by reintroducing some emacs-internal laziness in a more controlled fashion.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]