Paul Evans wrote:
> 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.
It might very well make the difference between nobody switching over
and this becoming a widespread feature.
> 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
:map <Esc>[65;5u {whatever}
> 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.
I haven't heard anybody ask for "ignore unrecognized keys" (which
technically means CSI sequences). I don't think it's much of a problem.
But it would be possible to optionally do this.
> > 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?
Just like key combinations with CTRL, ALT and SHIFT may be used for
something else, different keyboard layouts provide different keys that
users may want to use for something else. And these should match the
labels on the keys, of course. It might be something that's
added later, but it must certainly be thought of from the start. E.g.
for the modifiers that are possible. E.g. Mac has the CMD key.
Note that the SHIFT modifier must be supported, but depending on what
key it's used with it may be included in the base character. That's one
of the areas where things get complicated: is CTRL-I the I key with
SHIFT and CTRL pressed or not? This gets even more complicated for
keyboard layouts where special characters are not on same keys. Where
CTRL-8 means something on one keyboard, another keyboard has it on
CTRL-9. A user could set it up for one keyboard layout, but sharing
that to users on another keyboard won't work well. Or even for the same
user on another computer. You quickly end up with a non-portable set of
key mappings.
--
The term "free software" is defined by Richard M. Stallman as
being software that isn't necessarily for free. Confusing?
Let's call it "Stallman software" then!
-- Bram Moolenaar
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
