On 16/04/11 12:45 AM, Paul LeoNerd Evans wrote:
Having recently dredged this topic up again - what is the current state of plan? Are we happy we have a working model of how things will work and are just awaiting time to write some code, or are there still questions lingering about?
I think we've been making some good progress, but there is still plenty that needs to be discussed. Some of my thoughts: - It sounds like changing the internal Vim byte-stream representation for keypresses to actually be CSI could be a good idea. By making careful use of the private area we could ensure Vim can represent everything it needs to, plus almost by definition it can represent all the keys/modifiers required, plus it is somewhat future-proof. Does anyone have any objection to this? - I have one possible objection: I'm interested in how close to losslessly we can convert between registers (which can hold keypresses) and buffers (which cannot). In many encodings, it cannot be done losslessly, but in UTF-8, which is very common these days, perhaps it can. I suspect perhaps CSI was designed with this in mind. Does anyone know if CSI sequences are ever valid UTF-8 or are designed not to be? If they are not ever valid UTF-8 we have the nice situation that there isn't an ambiguity between keypresses and characters. If not, perhaps designing something with that property would be wise, rather than using CSI. - 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. - More importantly, though, we need some unambiguous specification of when to use the rich key representation and when not to use it. I think this needs a fair amount of further discussion. E.g. when Vim receives ^M from a terminal, should it leave it as ^M or should it convert it to a CSI sequence? What about in the GUI? What about when keys are stuffed into the input buffer? What about when storing the LHS and RHS of a mapping? - Finally, we need to finish discussing how mappings will be triggered. - My initial thoughts on this: Vim should use generic non-CSI codes when ambiguity exists: That includes when it receives codes from a terminal which are not CSI, so e.g., when receiving ^M which could be Enter or Ctrl-M, it should just store it as ^M. However, when it receives a key in the GUI or via CSI and it knows specifically it was produced by Enter or Ctrl-M it should store it specifically using CSI. For backward compatibility reasons, existing <>-notation should be considered ambiguous, but we should come up with an extension of this notation to be considered specific. Perhaps just adding an extra character after the opening '<'--for instance <!Enter> could mean Enter, specifically. When interpreting keypresses, specific keypresses would trigger specific mappings, or ambiguous mappings if no corresponding specific one exists; ambiguous keypresses would never trigger a specific mapping. This means you could map <Enter> and it would work in dumb terminals and the GUI, and existing plugins would keep working in both, too, including when you actually press Ctrl-M. However, in the GUI/smart terminal, you could override that default/ambiguous map, by mapping <!C-M> which would take precedence, but only be active when we are sure Ctrl-M was pressed and not Enter. Do others think this approach would work? 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
