[Top][All Lists]
[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.
- Re: Selection changes, (continued)
- Re: Selection changes, Chong Yidong, 2010/07/16
- Re: Selection changes, Miles Bader, 2010/07/16
- Re: Selection changes, Chong Yidong, 2010/07/16
- RE: Selection changes, Drew Adams, 2010/07/22
- Re: Selection changes, Chong Yidong, 2010/07/22
- Re: Selection changes, Eli Zaretskii, 2010/07/23
- Re: Selection changes, David De La Harpe Golden, 2010/07/24
- Re: Selection changes, Eli Zaretskii, 2010/07/24
- Re: Selection changes, David De La Harpe Golden, 2010/07/24
- Re: Selection changes, David De La Harpe Golden, 2010/07/25
- Re: Selection changes,
David De La Harpe Golden <=
- Re: Selection changes, Chong Yidong, 2010/07/16
- Re: Selection changes, Chong Yidong, 2010/07/17
- Re: Selection changes, David De La Harpe Golden, 2010/07/17
- Re: Selection changes, David De La Harpe Golden, 2010/07/18
- Re: Selection changes, Wojciech Meyer, 2010/07/17
- Re: Selection changes, Miles Bader, 2010/07/17
Re: Selection changes, Angelo Graziosi, 2010/07/15