On 17/04/11 15:23, Ben Schmidt wrote:
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.
What about the users who have trained their fingers to hit Ctrl-[ when
they need <Esc> because the Esc key is too far out of the way? Will they
be left stranded? Similarly, perhaps, with Ctrl-I and <Tab>, Ctrl-? and
<Del>...
Best regards,
Tony.
--
A man wrapped up in himself makes a very small package.
--
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
