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

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.