On Mon, 06 Oct 2014 17:54:47 +0200 Bram Moolenaar <[email protected]> wrote:
> This hack means backwards compatibility is dropped, it can't be > included without breaking lots of things. Don't forget that users > today rely on CTRL-I doing the same as Tab. Only when they are > mapped separately should the mean something different. Don't forget that users tomorrow want to rely on CTRL-I doing something differently to Tab. > Your page doesn't say how to switch between the old mode, where CTRL-I > produces a 0x09 character, and one where it produces a different > character. This is required for the terminal to be used with programs > that do not support the new codes. One can't expect to have all > programs that a user uses to suddenly accept the new characters, thus > a switch between two modes is required. Ahyes; I suppose it should probably use a mode setting, to enable it and default off until some application wanted to enable it. I'll give that some thought - hopefully Thomas and I can find a suitable mode number for it. In any case, I suspect that's going to be a minor cornercase of the specific keys of Ctrl-I, Ctrl-H and Ctrl-J overlapping with Tab/Backspace/Enter. The remaining ones, like Ctrl-Shift-A, Alt-letter, etc... are already key combinations that people won't be typing unless they mean it. And lets not forget that already for years, terminals have been sending such key events like Ctrl-Shift-Up as CSI 1;6 A and thus confusing most input systems pre-existing. Already vim handles these with the * hack. I'd love to see the "if $TERM==xterm then use the * hack" code replaced with a nice proper generic CSI parser, which will then understand these sequences. If nothing else, vim should at least recognise an incoming CSI 65;5u when it sees it as being Ctrl-A, rather than its current behaviour of getting confused, beeping, leaving insert mode, repeating the last t motion 65 times, then undoing my last 5 changes. That isn't helpful in the slightest. Even if you do nothing else from this discussion, I wouldn't mind if you made vim handle these CSI encodings a little better - undoing my last 5 changes is never what I wanted to happen :) There's surely no danger in interpreting these incoming sequences correctly /if/ you happen to see them - whether or not you see them is then up to the terminal. > Vim could switch to the new > mode and take care of a default set of mappings to the old meaning. > That's a lot of work though. I'd be happy to write you a set of default :map/:map! commands to remap the new to the old, if that would work. > Also, I don't see any note about different language keyboards. There > are many, and the mechanism should work for all, with proper > documentation what happens for different keyboards. Also, I don't see > anything for keypad keys, the numlock key and other keys that some > keyboards have that change what other keys mean. Numberlock has no bearing on this - numberlock is what is used to change the number keypad between cursor/application sense, and plain number sense. In effect, with numberlock on the numberpad should act identically to the regular number keys; with it off it should act identically to the cursor control keys. As to other language keyboards I'm not quite sure what concern you have here. Other language layouts add new Unicode symbols that wouldn't otherwise be accessible - this scheme already copes just fine with Unicode. E.g. if you now find yourself with a real Ä (U+00e4 / U+00c4) key, that's no problem. U+00c4 is 196 decimal. Ctrl-Ä, for example, is then represented by CSI 196;5u. Does this answer your concern, or is there still something remaining here? -- Paul "LeoNerd" Evans [email protected] http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
