[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: Sun, 18 Jul 2010 17:24:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100620 Icedove/3.0.5

On 17/07/10 05:13, Chong Yidong wrote:
Chong Yidong<address@hidden>  writes:

David De La Harpe Golden<address@hidden>  writes:

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.

Let's come up with a proper fix, first.

To be precise, the check is necessary because otherwise mouse-1 (which
deactivates the mark) destroys the primary selection.

Okay, just saw rev. 100841:

Do you still think the remaining zero-length problems (still present in certain situations) are worth addressing?

Personally I'm not all that bothered by them, but I've been using an emacs with select-active-regions on for some time before any attempt to address them, so may have adjusted to avoid gotchas.

Anyway, I did say I'd propose something:

My initial stab wound up fugly, negating the efficiency of the lazy buffer query approach, doing buffer-substring ops before every command
to freeze off a copy of the region out of paranoia.

*** Then I hit upon an extra pair of markers to freeze the pre-command-execution extent of the region before each command, since x-set-selection can also take a cons of markers to lazily query.

It seems to work quite well, and doesn't buffer-substring gratuitously. I've yet to convince myself my actual implementation is 100% correct and it may be still kind of ugly, but shouldn't be grossly inefficient.

On the plus side, with the patch, C-SPC C-SPC sequences and clumsy clicks no longer nuke primary.

Anyway, see attached. Perhaps not quite suitable for inclusion in its current form, but maybe the approach/idea is basically viable?

I have included debugging messages in the patch in its current state: It may be useful to split your window to show *Messages* and (setq select-active-region-debugging t) with it applied and try some selections. Or just confusing.

Other dumb issue: turns out I don't know how to make C code use defcustom variables - really, the calls introduced in the command loop need to be avoided if at all possible, given where they are, and so should also be guarded by !NILP select-active-regions, but apparently declaring the variable on the C side is the wrong thing to do.

Attachment: select-active-regions_nozerosized_r1.diff
Description: Text Data

reply via email to

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