Re: Supporting more key modifiers (was: Re: Dear Bram)
- On Fri, Feb 25, 2011 at 02:43:23PM +0100, Bram Moolenaar wrote:
> So the problem is that many users expect CTRL-M to have the same effectThat's OK. For them it can be mapped. Or even made default.
> as Enter, just like people use CTRL-[ instead of Esc. And a few people
> would make the CTRL-M act different from Enter, and CTRL-[ different
> from Esc.
> First problem is to actually detect what key was pressed, in mostChanging terminal emulators is a done task; xterm has supported this
> terminal emulators this is not possible. In the GUI we can. Changing
> terminal emulators to support this and making this work with Vim is a
> separate issue, I'll not go into that here.
since 2008. In fact I asked Thomas Dickey to clarify this for me, and he
informs me it's all present and working.
> Then we need a way to make the extra information available to be used inReally?
> mappings, without breaking it for users relying on the current way.
> Some things that are no acceptable:
> - Have a setting to enable "the new way".
Is that what we'd have said right back at the beginning of Vim? On the
subject of the 'compatible setting:
"Adding a setting to enable all the vim-incompatible changes, is too
complex for users to handle."
> This will break existingRight now we have users _all the time_ pulling their hair out _because_
> stuff and make users pull their hair out because they don't know this
> setting exists. Forget it.
such a setting does not exist. Including myself. I would much rather
have to support hoards of confused users in #vim by saying to them
"Yes, sorry your vim can't recognise that keypress now, but set this
setting and then it will"
"No, sorry your vim cannot recognise that keypress at all"
If you would prefer to support people by telling them it is not
possible, rather than telling them how to make it possible, please come
to #vim and explain that to them. Every week.
> - Change the input queue from a stream of bytes to some list of structs.OK, well that's fair. It was intended as an implementation detail in any
> This isn't adding any functionality and breaks all kinds of mapping
> and termcode handling, register execution, etc. Forget it.
case. I hadn't realised it would be possible with the existing byte
As long as the two triplets of keypresses I suggested originally can all
be represented uniquely, and without reference to timing information in
the Escape vs Alt+ case, then I'm happy with whatever internal
implementation makes it happen.
> What we can do is extend the existing modifier byte sequence.<snip long description>
That all sounds a bit long and complicated, and I'm not sure I see
whether it's necessarily any easier to implement than the arguably
much-neater and more forward-compatible queue-of-structures idea I had
originally. But again, that's all internal implementation details -
whatever makes it work, I'm happy with.
> We also need a way to specify mappings with the new modifier, perhapsX for "eXtended"? Could work, though would be useful to check that
> using a special modifier X, thus you could do:
> :map <X-C-[> :echo CTRL-[<CR>
> :map <X-C-I> :echo CTRL-I<CR>
doesn't collide with any named modifiers on any existing system. Perhaps
some non-letter punctuation symbol? Though nothing suitable comes to
Paul "LeoNerd" Evans
ICQ# 4135350 | Registered Linux# 179460
- On Tue, 21 Oct 2014 20:49:40 +0200
Christian Brabandt <cblists@...> wrote:
> > In theory, yes. In practice, last time I looked xterm didn't do itpangoterm, or continue prodding at xterm until it does the right
> > quite right yet.
> > The setting is called modifyOtherKeys but the problem with is was
> > that it either modifies too little (leaving such pairs as Ctrl-a and
> > Ctrl-Shift-A indistinct), or modifies too much (using CSI u encoding
> > for a plain Ctrl-c keypress, thus meaning termios doesn't recognise
> > it and send a SIGTERM). I have re-raised this with Thomas just now;
> > I'll see if we can get to a point where it's just in the middle, and
> > therefore right.
> So what would be the preferred way to actually see those keys?
> Installing pangoterm?
Or provoke your preferred terminal's author into fixing it.
More consensus among terminals => better.
Paul "LeoNerd" Evans
http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS