-- "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> spake thusly:
>>>>> "mb" == Martin Buchholz
<martin(a)xemacs.org> writes:
mb> The current behavior has the advantage that the bindings of up
mb> and shift-up do not need to be kept in sync. Then modes that
mb> redefine keys like up do not have leftover confusing bindings
mb> for shift-up.
I have no idea what you are talking about. ;-)
I find the current behavior extremely confusing, especially since if
you establish a region with a shift-motion key the next unshifted
motion key deactivates the region, while if you establish a region any
other way, the next motion key (shifted or unshifted) extends the
region.
There is no rhyme or reason to this behavior. It's a purely personal
implementation being imposed on the world, requiring that the poor
unfortunate user has to experiment to find out which keys are
affected, and precisely how. And what happens if you fool with
zmacs-regions? Undocumented!
On the other hand, unsynchronizing the documentation from the standard
gestures is unforgivable.
Unless somebody comes forward and commits to fixing and maintaining
that documentation until they find another volunteer, I'm ripping it
out (if it's reasonably eay).
I've got a slightly mangled version of CUA-mode which I use for exactly
this sort of functionality, and which does the right thing most of the
time. For instance, unshifted motion _always_ deactivates the region,
and it works properly with zmacs regions, although is broken without.
Should I work on trying to merge it with this stuff, wherever it is?