- Whatever byte-stream representation we land on, though, we would need
a more careful survey of what internal Vim things are needed, and a
sensible design for using the private area. That shouldn't be too hard
and probably doesn't need to involve the community too much.
What things did you have in mind that would even need the private use
area? Would these be non-keypress events? The CSI model is able to
represent any of the keypresses already, so I'm not sure what's left to
consider.
You're spot on. Vim currently uses its internal keypress representation
also to represent mouse clicks, mouse scroll wheel, 'script specificity'
(i.e. <SID> used to access s: functions from mappings), representing the
CSI 'character' and possibly more that I've forgotten, so if we change
Vim's internal representation to be CSI, we would need to integrate
these kinds of things (or have two 'escape mechanisms', but that seems
like a very dumb idea to me).
The way libtermkey handles this is that it has a set of "translations",
better names for some sequences. It renames 0x08 as "Backspace", 0x09 as
"Tab", 0x0d as "Enter" and 0x1b as "Escape". Any of the other C0s take
their Ctrl-[letter] interpretation. This can be disabled by a flag.
I guess the puzzle for Vim will be knowing when to turn that flag on and
off. I guess it should be fairly simple to figure out from $TERM and/or
somehow querying the terminal.
This is important for terminals to still match users' expectations with
regards to the keys they press to get various termios handling. termios
can only store a single byte value for the various events, so, for
example, EOF has to be 0x04, the single-byte representation of "Ctrl-D".
Mmm. Most importantly Ctrl-C for interrupt, I suppose. Others, like stop
and continue and status, are not really used in Vim, so don't really
concern us. O, I guess suspend is used, too. I suppose Vim deals with
both of these by intercepting signals rather than parsing the keys
though. But maybe not.
So, I would say, there are 4 keys which tend to go by different names:
Ctrl-H => Backspace
Ctrl-I => Tab
Ctrl-M => Enter
Ctrl-[ => Escape
The others are relatively uncontentious and can be left as-is.
So, are you saying that these four keys are ambiguous? Surely not!
Are you saying that these four keys, when actually generated with Ctrl
use CSI, and when not generated with Ctrl use a single byte, but other
Ctrl letters always use a single byte, since they can't be generated
without Ctrl anyway?
I guess it doesn't really matter, as long as Vim knows what's going on,
so can correctly identify the key from the bytes it receives.
Though does that still handle such cases as the physical keys Ctrl-C
vs Ctrl-Shift-C? Can I ask to map <!Ctrl-C> to mean only the
lowercase, without the (implied) uppercase including shift?
I think that's a good idea. I guess in the end we aim for consistency,
so it could depend how things like meta and accented keys work whether
it's truly a good idea or not. I would prefer it if case didn't matter,
though.
Ben.
--
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
