Alt+#
Personman
with mapping Alt+# keys for buffer switching. However, at the moment
it's an irritating process with an unpleasant trade off (apparently in
the form of being unable to have full UTF-8 support with such mappings
in force).
I'm posting this at eir suggestion in the hope of indicating that
there is significant demand for this to be resolved. It really is a
nice feature to have, and if LeoNerd is to be believed, it's not
terribly difficult. There was some debate on that point, and I'm not
qualified to evaluate it, but here it is just so everyone is on the
same page:
10:50 < LeoNerd> I want this to Jsut Work. For everybody.
10:50 < LeoNerd> I want people never again to have to ask how to do it
because it would just work.
10:51 < LeoNerd> What I already do have is plenty of example programs
that Bram is welcome to look at / copy / steal code / whatever that
demonstrates that this REally Is Not A Hard Problem
10:51 < LeoNerd> All he has to do is copypaste some .c code and it
will work
10:52 < Zathrus> it's not *that* simple, and you know it, if only
because of things like macros.
10:53 < LeoNerd> I don't know it. I've never looked at vim's source
code. I have no idea what macros you refer to
10:53 < Zathrus> (or, more accurately, registers)
10:53 < LeoNerd> Huh?
10:53 < LeoNerd> This is nothing about the registers.
10:53 < Zathrus> yes it is, because a macro is just a register fed to
the input queue
10:53 < LeoNerd> And?
10:53 < LeoNerd> We solved that. That's simple
10:55 < Zathrus> in my failed attempt to get the discussion alive
again I pushed registers off to a "we'll have to look at it" issue,
because the way they're stored currently means there's absolutely no
way to differentiate ^[ and <ESC>
10:55 < LeoNerd> Huh... YEah, that's trivially simple as well
10:55 < LeoNerd> A real escape key is just a CSI_SPECIAL
10:56 < LeoNerd> Vim has these bizarre "this isn't a key" keys, a
special sequence it puts in the queue. Apparently I wasn't aware of
that
last time
10:56 < LeoNerd> So just use those to store all the tricky structural
keys, and escape.
10:56 < LeoNerd> Or rewrite every Escape-prefixed CSI sequence into a
_real_ CSI-byte using sequence
10:56 < LeoNerd> Then the only Escape byte you ever see in the queue
comes from the real <Escape> key
10:57 < LeoNerd> And thus is never ambiguous
10:57 < LeoNerd> There. Done. :)
Ben Fritz
> I've just received some lovely help from LeoNerd in #vim on freenode
> with mapping Alt+# keys for buffer switching. However, at the moment
> it's an irritating process with an unpleasant trade off (apparently in
> the form of being unable to have full UTF-8 support with such mappings
> in force).
>
> I'm posting this at eir suggestion in the hope of indicating that
> there is significant demand for this to be resolved. It really is a
> nice feature to have, and if LeoNerd is to be believed, it's not
> terribly difficult. There was some debate on that point, and I'm not
> qualified to evaluate it, but here it is just so everyone is on the
> same page:
>
We've had this discussion many times. I think everybody agrees it's a feature that's wanted. Yet nobody, including LeoNerd, has come forward with any code whatsoever, working or not. If it was actually a simple "copypaste some .c code and it will work" sort of problem, then it would be done by now.
Paul LeoNerd Evans
> We've had this discussion many times. I think everybody agrees it's a
> feature that's wanted. Yet nobody, including LeoNerd, has come forward
> with any code whatsoever, working or not. If it was actually a simple
> "copypaste some .c code and it will work" sort of problem, then it
> would be done by now.
OK.
1) I have never been anywhere near vim's source code.
However, if someone here could tell me:
a) what to type to obtain working checkout
b) which file/line ultimately contains the code to insert a new
keypress into the pending queue when read from the terminal
c) how to use CSI_SPECIAL to insert arbitrary modifiers, such as
Ctrl-Shift-I.
Then I'll have a jolly good go at making this work.
Specifically, I'd love to see an example of some silly code somewhere
that just inserts something silly, like Ctrl-Shift-I once.
2) Take a look anywhere near libtermkey:
http://www.leonerd.org.uk/code/libtermkey/
Specifically the little demo at
http://www.leonerd.org.uk/code/libtermkey/overview.html
Observe that it has the ability to represent all of this lot just
fine.
Granted /and I accept/ that you will need a specially-configured
terminal to get "non-traditional" keypresses out of it like Ctrl-I or
Ctrl-Shift-[letter], but even without that, it will handle Escape vs.
Alt+letter vs. UTF-8 absolutely fine on any standard terminal. It's
this part most of all I want to add to vim, so everyone will benefit.
The fact I'll be able to map Ctrl-I and Ctrl-Shift-A and so on will
just a small added bonus.
--
Paul "LeoNerd" Evans
leo...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
Benjamin R. Haskell
> On Tue, Apr 17, 2012 at 12:59:53PM -0700, Ben Fritz wrote:
>> We've had this discussion many times. I think everybody agrees it's a
>> feature that's wanted. Yet nobody, including LeoNerd, has come
>> forward with any code whatsoever, working or not. If it was actually
>> a simple "copypaste some .c code and it will work" sort of problem,
>> then it would be done by now.
>
> OK.
>
> 1) I have never been anywhere near vim's source code.
>
> However, if someone here could tell me:
>
> a) what to type to obtain working checkout
>
> b) which file/line ultimately contains the code to insert a new
> keypress into the pending queue when read from the terminal
>
> c) how to use CSI_SPECIAL to insert arbitrary modifiers, such as
> Ctrl-Shift-I.
>
> Then I'll have a jolly good go at making this work.
>
> Specifically, I'd love to see an example of some silly code somewhere
> that just inserts something silly, like Ctrl-Shift-I once.
If it were as simple as pointing out where the central "Insert keystroke
into processing queue" functionality lives, my guess is that it'd have
been done already. (And we could move on to the "Yay! Finally! So, what
tweaks are left?" phase.)
I don't think Ben Fritz's intent was to say that you (LeoNerd) need to
be the one to implement it. Just that anyone complaining needs to
understand that it's not a trivial undertaking, and that no developer
with a high degree of Vim-familiarity has stepped up to do it yet. (I'm
getting really close, personally, but I'm probably a third-tier Vim
dev.)
The fact that it's not backwards compatible is also (unfortunately)
problematic (Cf. Tony Mechelynck's questions about whether <C-]> and
<Esc> will be identical in the future).
But that's a political question. (Personally, I tend toward "If
people/scripts rely on the broken behavior, too bad". But, if I were
the "benevolent dictator", there wouldn't be a 'compatible' setting.)
> 2) Take a look anywhere near libtermkey:
>
> http://www.leonerd.org.uk/code/libtermkey/
>
> Specifically the little demo at
>
> http://www.leonerd.org.uk/code/libtermkey/overview.html
>
> Observe that it has the ability to represent all of this lot just
> fine.
>
> Granted /and I accept/ that you will need a specially-configured
> terminal to get "non-traditional" keypresses out of it like Ctrl-I or
> Ctrl-Shift-[letter], but even without that, it will handle Escape vs.
> Alt+letter vs. UTF-8 absolutely fine on any standard terminal. It's
> this part most of all I want to add to vim, so everyone will benefit.
> The fact I'll be able to map Ctrl-I and Ctrl-Shift-A and so on will
> just a small added bonus.
How portable is libtermkey? I generally dislike the Vim party line on
backwards compatibility. But, being cross-platform is a good thing.
Also, last time I checked libtermkey out, there were quirks even with
the XTerm implementation of the "extended" sequences. E.g.:
On a U.S. QWERTY keyboard, where the row with numerals is:
unshifted: `1234567890
shifted: ~!@#$%^&*()
With <Shift> depressed, using the libtermkey demo, I get:
<S-~> ! <S-@> # $ % <S-^> & * ( )
That is: Depending on how you look at it: 8 of 11 characters don't
detect that <Shift> is depressed; or 3 of the characters that can't be
typed without <Shift> get an extra <Shift> modifier.
And even for the <Tab> <C-i> <C-I>, case:
<Tab> <C-i> <C-S-I>
(Why the capital 'I' in addition to 'S-'? Or is it just a libtermkey
demo convention?)
The Vim-relevant point to all this being: it seems like more
standardization is necessary (not sure from XTerm or libtermkey).
Otherwise we're going to trade "I can't map <C-i>" problems for "I can't
map <~> or <^> or <I>".
--
Best,
Ben H
Paul LeoNerd Evans
> The fact that it's not backwards compatible is also (unfortunately)
> problematic (Cf. Tony Mechelynck's questions about whether <C-]> and
> <Esc> will be identical in the future).
>
> But that's a political question. (Personally, I tend toward "If
> people/scripts rely on the broken behavior, too bad". But, if I
> were the "benevolent dictator", there wouldn't be a 'compatible'
> setting.)
Well, the politics are a largely-orthogonal part here, surely? Right now
the code doesn't exist so nobody can choose to run it. If it were to
exist, people could choose for themselves if they wanted to run it or
not, and we'd be able to weigh the choices and compromises and decide
what feels best. At the very least we'd be able ot offer to users "here,
have a patch you can apply if you want this thing but we think it's
dangerous". Right now we can't /even/ offer that.
> How portable is libtermkey? I generally dislike the Vim party line
> on backwards compatibility. But, being cross-platform is a good
> thing.
libtermkey will run anywhere with POSIX read() and poll() functions.
But even then, I didn't necessarily suggest simply using libtermkey. I
suggested that here is an existence-proof that detecting such keypresses
is easily possible, the code is MIT'ed so feel free to steal it, or at
least be inspired by ideas within it. It would be great if vim did just
use libtermkey, at least on suitable platforms, but I won't complain
(too much) if it doesn't and instead just reimplements the same
abilities from it. I care a lot more about the end-result than the means
used to obtain it.
Paul LeoNerd Evans
> with the XTerm implementation of the "extended" sequences. E.g.:
>
> On a U.S. QWERTY keyboard, where the row with numerals is:
> unshifted: `1234567890
> shifted: ~!@#$%^&*()
>
> With <Shift> depressed, using the libtermkey demo, I get:
> <S-~> ! <S-@> # $ % <S-^> & * ( )
>
> That is: Depending on how you look at it: 8 of 11 characters don't
> detect that <Shift> is depressed; or 3 of the characters that can't
> be typed without <Shift> get an extra <Shift> modifier.
>
> And even for the <Tab> <C-i> <C-I>, case:
> <Tab> <C-i> <C-S-I>
>
> (Why the capital 'I' in addition to 'S-'? Or is it just a
> libtermkey demo convention?)
>
> The Vim-relevant point to all this being: it seems like more
> standardization is necessary (not sure from XTerm or libtermkey).
> Otherwise we're going to trade "I can't map <C-i>" problems for "I
> can't map <~> or <^> or <I>".
Yeah, those unfortunately are an xterm bug.
While it does correctly make some attempt at implementing CSI u, it
fails to observe that the Shift modifier should specifically /not/ be
encoded in the modifier bits, because that modifier was used to obtain
the Unicode codepoint in the first place. Thus there is no "Shift-!" as
such, Shift is simply the modifier used to obtain !. By pressing the
three pieces-of-plastic labeled Ctrl, Shift, 1!, you should obtain a key
denoting <Ctrl-!>, encoded as CSI 33;5 u. Again you see it on your
Ctrl-I vs. Ctrl-Shift-I.
Potentially libtermkey ought to fix up these, and mask away the Shift
modifier on modified Unicode. But then you have to exempt Backspace,
Tab, Enter and Space... Fun times...
Øystein Walle
> there is significant demand for this to be resolved.
Regards
Øystein Walle
Tom Sorensen
> If it were as simple as pointing out where the central "Insert keystroke
> into processing queue" functionality lives, my guess is that it'd have been
> done already. (And we could move on to the "Yay! Finally! So, what tweaks
> are left?" phase.)
I certainly don't think this is going to be trivial... we're talking
about changing one of the central parts of vim, the input queue. Even
if the simple case is trivial (basic keyboard input) that doesn't mean
there aren't dangers lurking in macros, registers, maps, etc.
But that doesn't mean it's not worthwhile. Frankly, the vim input
mechanism is pretty broken nowadays. Contrary to what is in the
design-goals there are lots of keys that cannot be mapped, in either
terminal or GUI mode (ctrl-shift-anything, ctrl-0, ctrl-;). There are
keys that act identically for no apparent reason (ctrl-3 is <ESC>),
and there are keys that you really don't want to map (alt-anything)
because you can't tell the difference between the key and pressing
<ESC>key.
And while some of these limitations come from terminfo/termcap, they
carry over to the GUI for no obvious purpose.
> The fact that it's not backwards compatible is also (unfortunately)
> problematic (Cf. Tony Mechelynck's questions about whether <C-]> and <Esc>
> will be identical in the future).
Yes, they will. At least if you want them to be. I mentioned this in
my email a couple weeks ago -- vim should, by default, map <C-[> to
<ESC>, <C-i> to <Tab>, etc. But if the user wants it to be different
then they can do a map. The only people who would be bitten are those
who do something like:
:map <C-i> call <SID>MyTab()
And expect pressing <Tab> will call MyTab() if they're using the GUI
or a newer terminal that sends CSI sequences.
There really shouldn't be a backwards compatibility concern -- older
terminals will still send the same key sequences and vim will still
interpret them the same way. But at least we wouldn't be limited to
the lowest common denominator for terminals as we are now. It's akin
to not implementing colors at all because not all terminals can
display more than two.
Tom Sorensen
Paul LeoNerd Evans
> I certainly don't think this is going to be trivial... we're talking
> about changing one of the central parts of vim, the input queue. Even
> if the simple case is trivial (basic keyboard input) that doesn't mean
> there aren't dangers lurking in macros, registers, maps, etc.
Actually I thought we got to the end of the discussion last time of
saying that there is a mechanism (CSI_SPECIAL?) that does fit into the
existing queue, so we don't have to change it.
Again I'd like to restate my question: Can someone please provide an
example of how to use CSI_SPECIAL to insert Ctrl-Shift-A into the queue,
for example..? If anyone can do that then I can provide the rest quite
easily indeed.
If not, then we need to look into it in more detail, and at that point
it might become harder, yes.
Paul LeoNerd Evans
> I'll chime in and say that I too would like this functionality a great
> deal. It's unfortunate that I cannot make use of any key combination I
> wish and I think it makes Vim and other terminal programs seem older
> and less able than they need to be.
There's two related but distinct issues here, don't be confused:
1) Asides my recent work and xterm, no terminal /can/ represent
Ctrl-Shift-Letter, Ctrl-Tab, Ctrl-I as distinct from Tab, etc...
No terminal-based program can therefore distinguish the two
2) Vim itself conflates Escape letter, Alt+letter and UTF-8 sequences.
That is a behaviour very specific to Vim; most other terminal-based
programs can easily distinguish all these distinctly.
While I aim to fix, and have solutions for, both of these problems, only
the latter can be blamed on Vim. The first problem is inherent to any
terminal emulator or terminal-based program, and no specific blame can
be attached to Vim in regard of it.