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

From: Stefan Monnier <[email-masked]>
Date: Tue, 13 Mar 2012 09:23:01 -0400

severity 8996 important
thanks

> Hmm. bug #6872 was addressed by trunk r101176, which suppresses the primary
> update on handle_switch_frame, but, well, that only covers that immediate
> frame switch case.  Kinda need to address switching between individual
> windows too (or actually instead since handle_switch_frame will always wind
> up calling select_window itself, I think).  However, select-window itself is
> not a command afaiui, and enumerating all potential window-switching
> commands is probably not viable.  I can't say I like the attached solution
> (modelled on the deactivate-mark variable) very much, though nor did I have
> any especially better ideas.

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.

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.

Along the same lines, another approach that doesn't pay attention to
windows is to record the current buffer and the region's status
before running the command, and only do the select-active-regions is the
buffer is the same and the region's status has changed.

        Stefan