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

[David De La Harpe Golden <david@harpegolden.net>]

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?