Ben S wrote:
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 H wrote:
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>.
Tony wrote:
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>...
I guess that's a third type of person.
Continuing what Ben H wrote:
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.
I think I probably agree with that. But apart from these 2 or 3 types of
users, we have to consider terminals. There are still plenty out there
that just give us ^M for Enter or Ctrl-M.
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).
OK. So let's consider that a fallback option for a while and explore
some other directions.
Ben S wrote:
Possibly better: the LHS of a mapping if using <>-notation could map it
both specifically and ambiguously, and when used for stuffing keys into
the buffer (including RHS of mappings), <>-notation could always be
specific. This would mean if you mapped both <C-M> and <Enter>, each
specific key would trigger the appropriate mapping, but ambiguous keys
would still trigger whichever mapping was defined last. So old stuff
would continue to work as expected, but new stuff would work somewhat as
expected, too. The <!Whatever> notation, or perhaps some mapping
modifier like <specific> could be used to indicate that only the
specific LHS should be mapped, not ambiguous, giving a way of avoiding
accidentally affecting <Enter> when mapping <C-M>.
Would that be an acceptable compromise?
Another possibility, further building on this, would be to allow
specific keys to trigger only specific maps, and ambiguous keys to only
trigger ambiguous maps, but make an ambiguous LHS of a mapping actually
define both ambiguous and specific maps.
I think my reply is going to get as confusing as Ben H's earlier email
here...but let me try to summarise possible approaches:
APPROACH 1:
- Ambiguous LHS defines ambiguous map
- ^M defines ^M
- <>-notation LHS defines ambiguous map
- <C-M> defines ^M
- <Enter> defines ^M
- <!>-notation LHS defines specific map
- <!C-M> defines CSI-Ctrl-M
- <!Enter> defines CSI-Enter
- <>-notation on RHS is ambiguous
- <C-M> generates ^M
- <Enter> generates ^M
- <!>-notation on RHS is specific
- <!C-M> generates CSI-Ctrl-M
- <!Enter> generates CSI-Enter
- 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
- Benefits
- Existing mappings continue to work exactly as they currently do
- Drawbacks
- Requires <!> notation to do anything specific
- Specific stuff will never work in an ambiguous terminal, so more
work for users to support both terminal types
APPROACH 2:
- Ambiguous LHS defines ambiguous map
- ^M defines ^M
- <>-notation LHS defines specific and ambiguous maps
- <C-M> defines ^M and CSI-Ctrl-M
- <Enter> defines ^M and CSI-Enter
- <!>-notation LHS defines specific map only
- <!C-M> defines CSI-Ctrl-M
- <!Enter> defines CSI-Enter
- (variation: :map <specific> instead of <!...>)
- <>-notation (or <!>-notation) on RHS is specific
- <C-M> generates CSI-Ctrl-M
- <Enter> generates CSI-Enter
- 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
- Benefits
- 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)
- Existing code could even start working as expected in some cases
- Does not require <!>/<specific> notation much
- Maps would often work in ambiguous terminals
- Drawbacks
- Some old stuff would break
- Still requires <!>/<specific> notation sometimes
APPROACH 3:
- Ambiguous LHS defines ambiguous and specific maps
- ^M defines ^M, CSI-Ctrl-M and CSI-Enter
- <>-notation LHS defines specific and ambiguous maps
- <C-M> defines ^M and CSI-Ctrl-M
- <Enter> defines ^M and CSI-Enter
- <>-notation on RHS is specific
- <C-M> generates CSI-Ctrl-M
- <Enter> generates CSI-Enter
- Ambiguous key triggers ambiguous map
- ^M triggers ^M
- Specific key triggers specific map
- CSI-Ctrl-M triggers CSI-Ctrl-M
- CSI-Enter triggers CSI-Enter
- Benefits
- No <!>/<specific> notation
- 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)
- Existing code could even start working as expected in some cases
- Maps would often work in ambiguous terminals
- Drawbacks
- Very little control over which mappings an ambiguous terminal
triggers (can't define a mapping to be ignored in the face of an
ambiguous terminal)
- Perhaps hard to enumerate all possible mappings to define from
<>-notation
- Probably inefficient due to that enumeration
- Some old stuff would break
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).
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
