Re: shifted arrow keys and the region (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."