emacs-devel
[Top][All Lists]
Advanced

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

Re: Selection changes


From: David De La Harpe Golden
Subject: Re: Selection changes
Date: Sat, 17 Jul 2010 04:50:32 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Icedove/3.0.5

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.






reply via email to

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