On Wed, Apr 20, 2011 at 09:22:23AM +1000, Ben Schmidt wrote:
Nevertheless, we still have two things to
test here: the situation where Vim gets ^I and doesn't know whether it's
Ctrl-I, and the situation where Vim gets ^I and knows it can't be
Ctrl-I, because it knows Ctrl-I would have been
On Wed, Apr 20, 2011 at 11:21:01AM +1000, Ben Schmidt wrote:
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
On Wed, Apr 20, 2011 at 09:46:49AM +1000, Ben Schmidt wrote:
What things did you have in mind that would even need the private use
area? Would these be non-keypress events? The CSI model is able to
represent any of the keypresses already, so I'm not sure what's left to
consider.
You're spot
If A3's not a showstopper, though, maybe the best next step would be
to start a test suite, to ensure things are working the way they're
supposed to work. Plus it gives a spec to shoot for. Things to
include would definitely be these sets:
Tab Ctrl-I Ctrl-Shift-I ^I
C-m Enter ^M
C-[ Esc
- 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.
What things
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
On Sat, Apr 16, 2011 at 02:50:17PM -0400, Benjamin R. Haskell wrote:
Q1. Need to change the input queue structure?
A1. Changing this requires many other changes, and it's not clear
that there's a whole lot to be gained for doing (very) much work.
The current queue isn't so terrible, it's
On Sun, Apr 17, 2011 at 11:23:34PM +1000, Ben Schmidt wrote:
- 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,
On Sun, Apr 17, 2011 at 10:19:57AM -0400, Benjamin R. Haskell wrote:
- 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,
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
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
Q1. Need to change the input queue structure?
A1. Changing this requires many other changes, and it's not clear that
there's a whole lot to be gained for doing (very) much work. The
current queue isn't so terrible, it's just not a nicely-packaged
struct.
Q2. Can current queue structure encode
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
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
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
On 17/04/11 16:19, Benjamin R. Haskell wrote:
[...]
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
- 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
On 18/04/11 02:31, Ben Schmidt wrote:
- 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
APPROACH 2:
- -notation LHS defines specific and ambiguous maps
- C-M defines ^M and CSI-Ctrl-M
- Enter defines ^M and CSI-Enter
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
On Fri, 15 Apr 2011, 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?
AFAICT,
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'm just prompted by again another question in #vim on the
21 matches
Mail list logo
