On Sun, 17 Apr 2011, 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?
That sounds reasonable to me. I use rxvt-unicode, though, which is
(apparently) the only major holdout from the xterm-keycodes monoculture.
So, I have a particular interest in making sure the conversion to/from
CSI works right. (Volunteering services, here. Not complaining.)
- 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.
Err, if you're using the 7-bit Control Sequence Introducer (\e[ = <Esc>
+ <[> = \033 \133), then CSI sequences are virtually always valid UTF-8.
The 8-bit single-character variant does avoid UTF-8, though. In a
properly formed stream of bytes, 0x9b is never the first character of a
UTF-8 sequence, since it has the appearance of a continuation byte.
- 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?
That's most of what my apparently-confusing response was getting at.
- 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.
Up to this portion, I agree.
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?
This is where I diverge. I really, really think that this needs to be a
break from backwards compatibility. The other portion of my
apparently-confusing response was that there are only two reasons that
people expect the key sequences <Ctrl>+<M> and <Enter> to be equivalent:
One: they know a lot about terminals and hysterical raisins.
Two: they've been bitten in the past where either: they were required to
input <Ctrl>+<M> when they wanted to be inputting <Enter>, or their Vim
mapping for <Ctrl>+<M> was "mysteriously" also triggered upon hitting
<Enter>.
I argue that users in *both* categories actually want mappings to
<Ctrl>+<M> and <Enter> to be distinct. And, that they want <C-M> to
mean <Ctrl>+<M> and <Enter> to mean <Enter>. Anyone writing a mapping
where the opposite is true is only working around a limitation of the
current implementation. Thus, a backwards-incompatible change is
beneficial.
What I think is a horrible idea is to introduce more notation to
keymappings that only serves the purpose of indicating "Yes, I really
mean it" (Though, to that end, I do like your use of '!' as the
indicator).
--
Best,
Ben H
--
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
