Plus, it's only the queue of incoming keypresses - that queue isn't going to stay very big for very long.
It's not just the input queue that's in question here, it's everywhere in Vim where keypresses are represented. For instance, the right hand sides of mappings are not primarily characters, but lists of keypresses. They need the same amount of expressive power to work properly. When macros are recorded, registers, which usually are primarily lists of characters, are used to store keypresses. Likewise, for feedkeys() to work, its input, a string, needs to be able to represent keypresses. And I'm sure there are plenty more subtleties. The bottom line, though, is that changing to a struct-based approach could make the job absolutely huge, requiring reworking and/or redesigning how maps, registers, etc. all work. And it might not even be possible since, e.g. registers need to be able to do both characters and keys. It would be much simpler to extend the current approach which uses an 'escape mechanism' for representing special keys. Just hit qq and type some arrow keys, q to end recording, and then inspect register q and you'll see what's going on here. Vim uses a byte <80> followed by two more bytes to represent special keys. IMHO, what needs to be done is for this to be tidied up and made consistent and documented so that these codes can be more readily generated, interpreted, and even viewed and understood by users (e.g. when I do :registers, it would be nice to see <S-Up> rather than <80><fd>^D, when appropriate). Included in this is a clear specification of what control characters mean, e.g. does ^I (<09>) mean tab or control-I? And which of those keys can or does use the escape mechanism? Then the behaviour of mappings needs to be defined--if there is a mapping for ^I (<09>) and I push tab, will it be triggered? If in a terminal which can't distinguish control-I and tab, and a ^I is received, should the mapping for Tab or control-I be triggered? If there's a mapping for ^I as well as Tab, which has precedence? All these kinds of questions need clear answers, and sensible specifications and design need to address them, avoid ambiguity, and take care to require as little as possible work for users, plugin authors, etc. to update their code and mappings. Then the input code needs to be reworked in all the GUIs and in the terminal handling to generate the appropriate internal codes, consistently across all the different GUIs, etc., in line with that specification/design. 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
