-
Notifications
You must be signed in to change notification settings - Fork 499
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ctrl-[ does not behave as Esc and CTRL-] as jump to ctag on Czech keyboard on Windows #2459
Comments
@zbyna |
I don't think that patch is relevant since it applies to gvim only. I'm not sure if we have enough information here to send the correct code to Neovim. The There is
Which corresponds to I do think that winit reports wrong here. It should probably report |
@risa2000 |
Neovim uses the terminal for the keyboard handling, and neovim-qt uses qt. We use winit, and this appears to be a bug in that library, for not providing us the correct information. |
@fredizzimo Thanks for explanation. I will try to create an issue related to https://github.com/rust-windowing/winit. |
@zbyna |
Just one technical clarification as I am not clear on what you meant by "gvim only". The original problem affected both |
Issue created: rust-windowing/winit#3621 |
Thanks the issue looks good, I can help filling in more details if needed when we get a response from the Winit team. |
Since Winit team does not respond, I created a temporary naive fix in my neovide fork zbyna@c12b001 . I am not daring to fix Winit because I have no experience with Rust at all. |
I dared to create fix in library: rust-windowing/winit#3696 I have a feeling 🙂 I will need some sort of support. Thanks. |
I give up rust-windowing/winit#3696 , this behaviour is due to the winit design decision how to handle CTRL+char. |
This table summarizes behaviour of the fix I prepared: |
Describe the bug
Ctrl-[
andCtrl-]
on Czech keyboard on Windows does not behave as in plain console Neovim a Neovim QT.I borrowed the text from this vim issue (thanks @risa2000), which is exact the same:
Ctrl-[
no longer behaves as Esc on Czech keyboard on Windows (it worked in g/vim 8)To Reproduce
Pressing
Ctrl-[
(or FWIWCtrl-]
) no longer works as expected (asEsc
, orgoto tag
). It writes the Czech letters instead:Ctrl-[
writesú
,Ctrl-]
writes)
.which are the actual letters on the Czech layout at the corresponding keys.
I did not check other
Ctrl-<??>
combinations.Expected behavior
From what I read in those and some other threads about the
Ctrl
handling I suppose there is a confusion among some people howCtrl-[
works on non English layouts. I will try to explain on the Czech layout on Windows.Note: For someone not familiar with Czech layouts, there are several "Czech" layouts with different degree of localization, but the one I will be talking about is the one named just
Czech
(the others are usually certain mix of English and Czech layout).On the Czech layout the key right to
P
(which on the English layout is the one with[
) has a Czech letterú
. The symbol[
is however written byAltGr+f
on the Czech layout. For English key]
(which is right to[
) the situation on the Czech keyboard is similar again - there is)
on Czech layout and]
is written byAltGr+g
.When Microsoft was localizing the keyboard they actually did a smart thing and did not map
Ctrl-[
toCtrl-AltGr-f
(as happened on some linux distros), but realized thatCtrl-[
is indeed a control code (and not an actual letter) and that the usability should be more important than formal correctness. We may say they did not localizeCtrl-[
by the character, but by the key (i.e. kept the same key in the layout regardless its localized character).I have been used to use
Ctrl-[
forEsc
and it worked in linux terminal, or Windows, regardless the keyboard layout for years. The only dire cases were GUIs in some linux distros where they indeed expected users to writeCtrl-AltGr-f
.There is an alternative deep explanation (another big thank @risa2000) which may be more appropriate for somebody:
vim/vim#12595 (comment)
Desktop (please complete the following information):
Please run
neovide --log
and paste the contents of the.log
file created in the current directory here:Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: