This is controlled by "shifted-motion-keys-select-region" which was added a few months ago. I believe the default is on for this behavior, but perhaps not. Another variable, "unshifted-motion-keys-deselect-region", controls whether the shift key has to stay down to continue selecting. Mike Alexander mailto:mta＠arbortext.com Arbortext, Inc. +1-734-997-0200 --On Friday, January 26, 2001 11:18 AM -0800 "A.J. Rossini" <rossini(a)blindglobe.net&gt; wrote:

John H. Palmieri writes: Yes. I'll fix the docs for 21.2 within a few days unless someone else gets there first. Maybe. Maybe I'll just revert the patch until it is correctly implemented, or the current bug-prone implementation is justified. NB: If you are on a slow enough connection, you will see that C-h k Shift-Down echoes "Sh-down" before describing "down." I do not understand why the behavior was implemented by detecting the keyboard state within the functions, rather than adding new functions to be bound to the Sh-motion chords. It is begging for exactly the bug you have reported. The only good reason I can think of at the moment is that somehow XEmacs doesn't really know about shifted motion keys, but that seems highly unlikely given that `describe-key' reports it correctly in the echo. Theoretically the programmer may have intended that the shift key be _continuously_ held down, but this is not the actual behavior. Shifted motion keys extend or retract the existing region, no matter how it was established, or whether the shift key is released in the interim (as long as you don't use unshifted motion ... hm, if you establish the region without shifted motion, then unshifted motion extends the region; oh, yuck). Yes. The absence is a bug, and the (ir)responsible programmer is sentenced to 20 lashes with a wet noodle. Yes. 20 more lashes. It's not just the arrow keys. It's all the non-ASCII-control motion keys. I'm going to have to grep for those damn variables to find out what to fix. This is evil, isn't it. This amounts to subversion of the self- documentation system. It _is_ possible to assign a different function to shifted ASCII controls (for perversity's sake, I tested this with `(define-key global-map [(control N)] #'previous-line)' which does what you would expect, and `describe-key' and `describe-bindings' both reflect the change). Can you guess how Shift-Down behaves if I substitute `(shift down)' for `(control N)'? I change the sentence to "40 lashes with a wet poodle." -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

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). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: It may be confusing for you, for me it's an excellent feature. If you select regions the Emacs way (C-SPC), you get traditional Emacs behaviour. If you do it the traditional GUI way (Shift-arrows), you get traditional GUI behaviour (deselect on unshifted arrow). Please don't spread such nonsense. The proper behaviour has been discussed on the lists many times! What Ben implemented is quite reasonable. No, you're not. If you are so bent to changing, fix the documentation.

Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Hrvoje> It may be confusing for you, Sorry. That was misleading. As a user I find it plausible. I was writing as someone who had earlier in the thread volunteered to document the behavior. I hereby unvolunteer; I'm confused and don't have time to get unconfused. Hrvoje> Please don't spread such nonsense. The proper behaviour Hrvoje> has been discussed on the lists many times! What Ben Hrvoje> implemented is quite reasonable. Again, I'm sorry. Emphasis is on _implementation_. This is an implementation _by a Windows user for Windows users_ that doesn't suck too terribly for traditional users (and some traditional users will like). However, as far as I can tell after some experimentation, the correct way to document it for traditional users is "Expect anomalies; we don't know what this code does in many circumstances. Mostly it does the right thing; you'll get used to it." Is that really acceptable to you? Hrvoje> No, you're not. If you are so bent to changing, fix the Hrvoje> documentation. No. This is _new_ code (ie, introduced since the devel branch opened), and it is not ready for prime time. It is undocumented (where users can find it) and unpredictable. It affects functions (`abbrevs-hacking-next-line' at least) outside of those bound to arrow keys in the default global map, and those effects are inconsistent with the behavior in the basic functions. And it breaks the keyboard functionality model (two gestures have different behavior iff their binding is different) and the documentation model. Therefore the default action, absent a thorough fix, is "the code comes out." Since there is support for the implementation, I will move it to the new devel branch which will open shortly, unless I see a consensus of the Review Board in favor of putting it in the release. As for who fixes it, I am Release Manager, not Default Coder for All the Features People Want But Don't Want to Do Right. It's not my job to put broken code into the release. The motion behavior is very close to correct, the implementation is wrong IMHO. It's another `delete-key-deletes-forward', which will suck up a man-year of someone's time (probably Martin's and Vin's). It's that man-year I'm aiming at saving, unless you (or another person who advocates this implementation) wants to contribute it specifically. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Hrvoje> This is not true. The code is tested and works well; The code does what those who like it want it to do. That's good. It also has unintended side effects. That's bad. Tell me, how does `abbrev-hacking-next-line' work when bound to C-n? You don't know without trying, do you, nor would it occur to you to try if I hadn't mentioned it. Very bad. Then tell me who is going to audit all motion code in the core and packages to find other such cases? The code breaks both the keymap model (keystrokes have different effects iff they are bound to different functions, and don't tell me about "immediate" functions like self-insert, that's different) and the documentation model (`C-h k' is sufficient to understand what a keystroke will do). This is downright evil. zmacs-regions are bad enough, they've been a bug/FAQ for years. If we document the `motion-keys-select-region' variables in every motion function, then we should do the same for `zmacs-region*'. And maybe others. We would also be setting a precedent that "keystrokes' meanings may depend on variables in arbitrary ways." I don't think we should go there. We can exempt zmacs-regions for "hysterical" reasons, but if we add more now, the door is wide open. Hrvoje> if you want to remove it, you get to prove why you want to Hrvoje> do so. Those are the rules of the game. Not for the release. The rules have changed. I've explained how this is going to work. The Release Manager says "no", and unless the Review Board overrules, the veto rides. You're welcome to try to get me fired, becaues I don't know myself if these are the "right" rules. But I need them to get my job done. My job is saying "no" to bad code. Because if nobody says "no" to half-assed code, we won't get a release, and XEmacs will suck. And the half-assed code will stay half-done. It doesn't matter if I make an occasional mistake; this may be one. But I am not going to spend more time worrying about it, because it's more important that I spend time laying the foundations for my successor. We have another release coming up in September, you know. You're a plausible candidate, Hrvoje.... As for the case in point, this is a good feature, implemented poorly and inconsistently with the way Emacsen are supposed to work, and _way_ underdocumented. Furthermore, I don't see (given the number of different ways motion code is warped in various packages and minor modes) how it _can_ be properly documented before the release. Show me a reasonably complete doc patch, including a halfway plausible argument that there aren't more a-h-n-l anomolies around to suck up maintainer time for the next year a la `delete-key-deletes-forward', and I'll back down. It's not my job to finish somebody else's incomplete feature, though. I'll carry water for the carpenters, but I'm not a carpenter myself. Hrvoje> Also note that you haven't named a single actual flaw the Hrvoje> code has. I named five in the message you responded to. And one more: this code is orphaned, bit-rot in a baby carriage. Nobody has volunteered to fix it (except me! but it's too time- consuming for me to do right, even the doc fix). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."