[Top][All Lists]

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

bug#8996: Set PRIMARY from last selection, not last selected window

From: David De La Harpe Golden
Subject: bug#8996: Set PRIMARY from last selection, not last selected window
Date: Sun, 18 Mar 2012 19:18:24 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0

On 13/03/12 13:23, Stefan Monnier wrote:

I think this approach isn't as terrible as it sounds (tho I don't much like
the name you chose, sorry).  We'd want to let-bind that new var in
things like save-selected-window, with-selected-window, ... which is
kind of ugly.

I dunno, maybe if 'tis getting time ordering right we're worried about, we should stop trying to make an ordering emergent from global state and impose one, probably more robust - save an actual timestamp or sequence number with saved positions (and restore it on position restore), and if the current selection postdates, it just shouldn't be reset (x11 selections are already timestamped anyway IIRC, dunno about other platforms).

Maybe a better approach is to record the selected window before running
a command, and only do the select-active-regions dance if the command did
not change the selected window.

Not convinced myself that covers commands that actually legitimately change the selected window and also set a new region, like maybe a mouse gesture. though turns out I'm now rusty in the area and may not have thought it through fully.

and only do the select-active-regions is the
buffer is the same and the region's status has changed.

I don't think that one can work - two different windows can routinely be open on the same buffer?

reply via email to

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