Some Shift+key not detected in neovim (non-stable) with non-qwerty keyboard layout
#1009
Closed
opened 1 year ago by cljoly
·
20 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
foot version:
or
I’m using a French dvorak-style keyboard layout (bepo) and I recently noticed that my neovim binding on
;
(which I enter withShift+,
,,
being on the physical keyg
on a qwerty keyboard) stopped working.This behavior is only exhibited by neovim on some yet unreleased
master
commits. Compiling neovim and runnig it like so (i.e. without any custom configuration and defining the mappings on the fly):allows to check this behavior on a locally built neovim from the git repository. On the latest neovim stable (
v0.6.1
), entering;
results in;
being displayed, but not on those latestmaster
commits. Usinggit bisect
, I’ve found this small commit to be the first with the;
mapping not working, while,
works.Meanwhile, the
;
mapping still works with Alacritty, for all neovim commits I tested. That suggests that foot might be sending the wrong sequence here.Just tested with Kitty, couldn’t reproduce the bug either.
Some Shift+key not detected in neovim (non-stable) with non-qwerty keyboardto Some Shift+key not detected in neovim (non-stable) with non-qwerty keyboard layout 1 year agoAlacritty does not recognize the
modifyOtherKeys
sequence (the one Neovim is setting in the commit you linked to), and we explicitly do not send the sequence for kitty since it uses its own encoding. Do you have another terminal emulator you can try to reproduce on?I am not familiar with foot's codebase, but I believe what's happening is:
CSI > 4 ; 2 m
which enables foot'smodifyOtherKeys
handlingShift + ,
this is no longer encoded as ASCII;
but insteadCSI 27 ; 2 ; 44 ~
(where2
is the modifier for Shift and44
is the decimal representation of,
). Neovim is then not interpreting this sequence properly.Can you also try reproducing in regular Vim by adding the following to your vimrc?
Could also be worth testing/comparing with xterm, which does support (obviously)
modifyOtherKeys
.Also note that foot supports kitty's keyboard protocol as well, so if neovim works better with that, another option is to change neovim to use the kitty kbd protocol (instead of modifyOtherKeys) on foot as well.
I also agree with @gpanders analysis, though I haven't verified it.
@cljoly I am not convinced that this is not a bug in Neovim, so could you also open an issue in our issue tracker?
Thanks for your quick feedback on this!
Tomorrow, I will:
I should be able to test with any terminal emulator installable from Arch’s repositories.
It appears XTerm is somewhat inconsistent here. For regular (a-z) keys, it produces a
CSI 27 ; 2 ; N~
escape for shift combinations. But for some, it does not, but instead produces a plain (but shifted) symbol.,
vs.;
is one such example. Most (all?) shift+number keys also behave like this (on my Swedish layout).However, it's not as simple as letter keys vs. non-letter keys; e.g.
-
produces aCSI 27
escape.This can be considered to be an issue with foot, in the sense that we're not producing output identical to XTerm.
But it could also be unintended behavior in XTerm.
Just tried reproducing, XTerm does not have the bug.
Trying to reproduce with vim:
Using foot 1.11.0, with this command:
vim gets the mapping for both
;
and,
. (athough it does not understand the<CR>
somehow, not a big deal, I get the partial:echo
command and that’s enough to test).EDIT: Tested with
vim -u DEFAULTS +'let &t_TE = "\<Esc>[>4;0m"' +'let &t_TI = "\<Esc>[>4;2m"' +'nmap ; :echo ";"<CR>' +'nmap , :echo ","<CR>'
as well, and both mappings work.For the corresponding GitHub issue: https://github.com/neovim/neovim/issues/18010 @gpanders
I’ve tried to Google how to get the escape sequence produced as one enters the the keys in the terminal, without success. Would you have any pointers on how you do that please?
In this case, you can do
But note that you'll probably find the terminal unusable after this...
For "normal" escapes, where you don't have to enable a specific terminal mode, just pressing ctrl+v before your key combo is usually good enough (you'll have to press ctrl+v before each combo).
Another option is
showkey -a
Thanks!
So in a newly opened terminal, I’m switching to the
CSI > 4 ; 2 m
mode and I enter,
then;
so
;
is sent asCSI 27 ; 2 ; 59 ~
, if I’m not mistaken.That seems inconsistent with our initial hypothesis
Correct. 59 is the key code for
;
. So it's basically saying, you pressed;
, andshift
is the (only) active modifier.If you do the same experiment in XTerm, you'll get a plain
;
instead. But for e.g. shift+a you'll not get a plainA
, but aCSI 27
escape.That’s right.
You said that to enter
;
you pressShift + ,
, right? But the escape sequence is reportingShift + ;
. I guess that might be the problem.It's no different from XTerm's CSI sequences.
For example, shift+a results in
CSI 27 ; 2 ; 65~
, where 65 is the decimal representation of upper caseA
.What I think XTerm is doing, is checking if the produced symbol (
A
) is the upper case version of the key's base symbol (a
). And if it is, it emits a CSI sequence.If it's not (for example,
;
is not the upper case version of,
), then it emits a plain symbol instead of a CSI symbol.I'll try to put together a POC for foot, to see if that improves our compatibility with XTerm.
Yes, that’s right.