On Wed, Apr 20, 2011 at 09:46:49AM +1000, Ben Schmidt wrote: > >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).
Mouse uses CSI M usually. Script mappings might be awkward... if they're purely numeric, then just pick another private-use value (say, CSI s). If there's a possibility of text in there, perhaps using an OSC would be better, as that still fits the ECMA-48 model and wouldn't be sent as real input by the terminal. > 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. (see comments in my other two replies) > >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. It's more a concern that the terminal continue to send the same byte for these keys so legacy programs can understand it, and also the kernel-implemented tty line discipline stuff. Things like SIGINT/SIGSTOP are implemented by the kernel. > > Ctrl-H => Backspace > > Ctrl-I => Tab > > Ctrl-M => Enter > > Ctrl-[ => Escape > > 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? That is my recommendation for terminal developers, yes. > 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. Indeed. And such logic is already fully implemented in libtermkey already. Which was the very start of the message threads that got us into this in the first place. Namely: That vim should use libtermkey to interpret the bytes it receives from the terminal, to report them internally as keypresses. The original thread got very side-tracked into how internally it should be stored. That's not important. If whatever mechanism internally used can represent these keypresses, then it won't be hard to feed them from libtermkey. -- Paul "LeoNerd" Evans [email protected] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
