Re: shifted arrow keys and the region (documentation?)

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."