Re: [c.e.x] Re: Change in kill-region in 21.4?

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&gt; 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&gt; ,-./-. 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. >