On 17/07/10 05:13, Chong Yidong wrote: > Chong Yidong writes: > >> David De La Harpe Golden 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.