GNU bug report logs - #8996
Set PRIMARY from last selection, not last selected window

Previous Next

Full log

View this message in rfc822 format

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 8996 <at> debbugs.gnu.org
Subject: bug#8996: Set PRIMARY from last selection, not last selected window
Date: Sun, 18 Mar 2012 19:18:24 +0000

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?

Previous Next

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