This seems to explain some of the marking oddities we have seen
recently. Any comments by whoever implemented the shifted-key stuff?
Gunnar
"James A. Crippen" <james(a)UnLambda.COM> writes:
> On Fri, 20 Apr 2001, James A. Crippen wrote:
>
> > I just upgraded from 21.2.14 to 21.4.1. I'm really happy with the
> > improvements in the new version, particularly with the increased speed and
> > with the new interface magic (like gutters and their buffer tabs and the
> > progress meter, both of which I think are wonderful).
> >
> > I've long had a set of keys bound for use with zmacs-regions, having spent
> > some time actually using ZWEI/Zmacs and being spoiled with the visual
> > feedback. <select> does `set-mark-command', then either <copy> does
> > `copy-region-as-kill' or <cut> does `kill-region'. They've worked
> > flawlessly since I bound them up until now.
> >
> > Now when I press <select>, move somewhere, and press either <copy> or
> > <cut> instead of the zmacs-region going away it persists with the mark
> > still set in the same place I originally set it with <select>. I can
> > cancel the mark with C-g without a problem, and the selected text is
> > either copied or killed to the kill ring and is perfectly yankable.
> >
> > I spent a few minutes looking at the source for `kill-region' and I can't
> > see anything particularly obvious that would cause the mark to remain
> > persistent.
> >
> > I tried manually setting the mark with C-space and then doing either of
> > M-x copy-region-as-kill and M-x kill-region. Done this way they work
> > properly and the zmacs-region goes away after the command.
> >
> > Here's the extract from my file of key defs. I can't see anything
> > obviously wrong with them.
> >
> > (define-key (current-global-map) [(kp-home)] 'copy-region-as-kill)
> > (define-key (current-global-map) [(kp-end)] 'kill-region)
> > (define-key (current-global-map) [(kp-delete)] 'yank)
> > (define-key (current-global-map) [(select)] 'set-mark-command) ;select is set to kp_5 with xmodmap
> > (define-key (current-global-map) [(control select)] 'keyboard-quit) ;cancel a selection
> >
> > Either I'd like to know if this is a bug or if a workaround for the new
> > functionality can be found. I can't tell what's wrong.
>
> After spending some quality time hunting around in simple.el and examining
> all the various places where `zmacs-region-stays' is set to `t', I found
> that the problem is due to the introduction of shifted motion
> keys. Particularly, the shifted motion key support is done in terms of
> *keys* and not in terms of the functions bound to them. This is so
> Sh-left will extend the region but C-F (which is Sh-C-f) won't because
> it's a different concept of motion key. The shifted motion effect is only
> bound to keys which are explicitly motion keys, and usually don't serve
> another purpose. Thus home, pgup, left, kp_end, etc are all considered
> motion keys in this sense.
>
> The shifted motion support naturally requires that `zmacs-region-stays' be
> set `t' for any shifted motion since otherwise the region wouldn't be
> extended. Thus the region was being *extended* nowhere in particular
> because my binding on kp-home for instance wasn't actually moving point
> anywhere (it's just calling `copy-region-as-kill') but
> `zmacs-region-stays' was being set anyway. Some work with Customize fixed
> this problem and now my bindings are back to normal operation. I could
> disable all the shifted region stuff and that'd probably fix the problem
> too, but I haven't tried it.
>
> Thought people should know...
>
> 'james
>
> --
> James A. Crippen <james(a)unlambda.com> ,-./-. Anchorage, Alaska,
> Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.2069 N, 149.766 W,
> Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
> Y(F) = F(Y(F)) \_,-_/ Milky Way.
>