On 19/04/11 12:43 AM, Paul LeoNerd Evans wrote:
On Mon, Apr 18, 2011 at 12:11:01PM +1000, Ben Schmidt wrote:
- Ambiguous key triggers ambiguous map
- ^M triggers ^M
- Specific key triggers specific map, or ambiguous if none
- CSI-Ctrl-M triggers CSI-Ctrl-M or ^M
- CSI-Enter triggers CSI-Enter or ^M
No terminal would ever be sending Enter as a CSI, because if it did so
no real program now would recognise it.
Understood. The terminal wouldn't be expected to, though. As detailed in
an earlier mail, any non-ambiguous special key would be turned into some
kind of CSI representation by Vim at input time. So if Vim knows a
particular terminal only sends ^M for Enter (because it uses CSI for
Ctrl-M et al.), and therefore, for that terminal, ^M is specific, Vim
would represent it as CSI internally. At mapping lookup time, then, it
would encounter CSI for Enter, if and only if it was unambiguously known
that Enter was pressed (or the Enter was generated by code in Vim such
as another mapping or feedkeys() using <>-notation).
On receipt of the single 0x0d byte we cannot tell whether this is an
Enter key, or a user of a "legacy" (i.e. non CSI-sending) terminal
pressing Ctrl-M.
It should know by $TERM or somehow, though, or be able to find out using
a callback or something, that the terminal supports or is in 'CSI mode'
where it will use CSI for Ctrl-M, though, right, and therefore deduce
that ^M is definitely Enter for that terminal?
APPROACH 2:
...
- Old stuff only breaks where <>-notation is involved; in this
case, the intent of the notation is clear, so breakages should
not be unexpected (except by gurus who were exploiting the
ambiguity anyway)
I foresee one major problem here - I suspect Bram himself is in this
camp, so is likely to raise significant objections if it involves him.
:(
Not wanting to put words in his mouth, but Bram's pretty reasonable, and
I'm sure like all of us will gravitate towards the best solution, when
the others have significant flaws/drawbacks (which I think they do).
And this is a very minor break in compatibility. It only occurs when you
have clashing uses of <>-notation. <C-M> would previously override an
<Enter> map, and vice versa, but with this approach it wouldn't. But
without such a clash, i.e. if you just used <C-M> or just used <Enter>,
it would behave just the same way as it does now (a map of one kind
would be triggered by the other key). So it's only really if you had a
couple of clashing plugins loading in a certain order to do what you
want, or you have some plugin that is inconsistent in how it refers to a
given key, that you have problems. Both these situations should be very
rare.
- Drawbacks
- Specific stuff will never work in an ambiguous terminal, so more
work for users to support both terminal types
You hit upon this here ;) No terminal would be set that way, so this is
a non-starter.
It doesn't require the terminal to be set any special way, partly
because of Vim converting to CSI at input time as I mentioned above. But
it does require more work by the user to support both old and new
terminals, and that would be a real pain.
Approach 2 looks like a clear winner to me so far. I think it would
be better with the <specific> map modifier than with <!>-notation,
though that would possibly cause problems if you want an LHS with
some specific and some possibly-ambiguous stuff; I doubt this would
be a problem in practice, though, and there is a workaround (use
intermediate mappings).
Is it possible to update approach 2, in light of the fact there are no
"non-ambiguous terminals", as such? I.e. that we can never tell if we
received an Enter on a CSI-sending terminal, vs. Enter or Ctrl-M on a
legacy one..., etc etc..
I think a good part of this is already catered for by the stuff I
mentioned above, i.e. Vim converting 'ambiguous' to 'specific' at input
time, because it knows that for the particular terminal in use it is
specific.
However, perhaps it is better to do things a bit differently so that ^M
prioritises Enter, since that is its 'more normal' meaning.
APPROACH 4
- Ambiguous LHS defines high priority (P1) ambiguous map
- ^M defines ^M-P1
- <>-notation LHS defines specific and ambiguous maps; priority of
ambiguous map is related to how 'simple' the key is--more modifier
keys mean a lower priority--keys that would usually be represented
without CSI have P1, so they replace mappings from ambiguous LHS
- <Enter> defines ^M-P1 and CSI-Enter
- <C-M> defines ^M-P2 and CSI-Ctrl-M
- <C-S-M> defines ^M-P3 and CSI-Ctrl-Shift-M
- <!>-notation LHS defines specific map only
- <!Enter> defines CSI-Enter
- <!C-M> defines CSI-Ctrl-M
- <!C-S-M> defines CSI-Ctrl-Shift-M
- (variation: :map <specific> instead of <!...>)
- <>-notation (or <!>-notation) on RHS is specific
- <Enter> generates CSI-Enter
- <C-M> generates CSI-Ctrl-M
- <C-S-M> generates CSI-Ctrl-Shift-M
- Ambiguous key triggers highest priority ambiguous map that is defined
- ^M triggers ^M-P1 or ^M-P2 or ^M-P3 or ...
- Specific key triggers specific map, or highest priority ambiguous map
that is defined if there is no specific map
- CSI-Enter triggers CSI-Enter or ^M-P1 or ^M-P2 or ...
- CSI-Ctrl-M triggers CSI-Ctrl-M or ^M-P1 or ^M-P2 or ...
- CSI-Ctrl-Shift-M triggers CSI-Ctrl-Shift-M or ^M-P1 or ^M-P2 or ...
- Benefits
- Those of approach 2
- ^M behaves more as expected for specific terminals (where ^M is in
fact used for one of the keys in the ambiguous set)
- Nicer unmap behaviour; e.g. if a plugin temporarily maps <Enter>,
when it unmaps it, even the ambiguous map of <C-M> becomes
'visible' again
- Drawbacks
- Those of approach 2
- Priorities must be sensibly assigned to all keys which might be
hard, ambiguous, keyboard layout dependent, or controversial
As before, this is conceptual. Implementation tricks will be needed to
make it efficient.
This is like Vim's local options: it is designed to mostly do what you
would expect, but doing what the user expects is a bit complicated...
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
