Re: Selection changes

[David De La Harpe Golden]

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.

select-active-regions_nozerosized_r1.diff
Description: Text Data