Re: Selection changes

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

On 17/07/10 03:56, Chong Yidong wrote:
>  So, for the
> moment, I went ahead and changed x-select-enable-primary to nil, as you
> requested.
>

Thanks, sorry for the rant. It's 4:50am, time for bed...

The bad "(not (eq (region-beginning) (region-end)))" check is still 
present in deactivate-mark (~simple.el line 3690) and should just be 
removed, I did [try to] explain the problem with it in a previous mail, 
that's a further source of some  poor behaviour (perhaps 
counterintuitively, but that's lazy stuff for you) that might be related 
to some of your points below.

> But I think select-active-regions needs further improvement.

No doubt...

 > Perhaps
> its default behavior should be as follows: for an active region created
> using shift-selection or mouse dragging, Emacs supplies the region text
> to primary.  When such a region is deactivated, Emacs disowns primary
> (as some other apps do, tho not Firefox).

Hmm. I do rather prefer the freezing off of the region into a string 
selection (line just after the bad check above) when deactivating rather 
than completely disowning - I mean, once you disown, the text won't be 
made available for middle-click insertion anymore and you'll be seeing 
"No primary selection" warnings a lot more.

Don't forget, the bad check mentioned above is negatively impacting 
behaviour in this specific area right now, if you remove the bad check 
line, the freezing off will work properly again.

> For an active region created
> simply with C-SPC, no special x-selection handling should be performed.
>

Well, not immediately owning primary on C-SPC /would/ stop most (all?) 
of the possible zero-length-region annoyances (unlike the "bad check") 
in their tracks, but it might be overkill to not own it at all if 
there's an (efficient) way to make emacs just defer taking ownership 
until the newly active region first becomes nonzero length.

That way, visibly highlighted regions would still act the same 
regardless of wether they were mouse/keyboardA/keyboardB created.