<C-6> mappings dont work #170
Comments
|
Ok we need to narrow this down a bit, Ctrl-number mappings should work, for example the following works for me in normal mode But other numbers e.g. 6 dont work I could use some more info about your setup
Here is a code snippet if anyone wants to debug it diff --git a/src/gui/shell.cpp b/src/gui/shell.cpp
index 05ca325..3f6996a 100644
--- a/src/gui/shell.cpp
+++ b/src/gui/shell.cpp
@@ -563,12 +563,14 @@ void Shell::keyPressEvent(QKeyEvent *ev)
// FIXME mousehide - conceal mouse pointer when typing
+ qDebug() << "Received keypress" << ev->text() << ev->key();
QString inp = Input.convertKey(ev->text(), ev->key(), ev->modifiers());
if (inp.isEmpty()) {
QWidget::keyPressEvent(ev);
return;
}
+ qDebug() << "Sending input" << inp;
m_nvim->neovimObject()->vim_input(m_nvim->encode(inp));
// FIXME: bytes might not be written, and need to be buffered
}For C-6 it gets me (Qt::key reference) |
|
Hi, thanks for your answer, see the solicited info bellow:
BR |
|
Update: BR |
|
In case you didn't aware. It seems Ctrl-6 is equal to Ctrl-^ in Vim.
|
|
I'm currently experiencing this issue. I use Environment: Windows 10 I'm not sure how to get the neovim-qt version but it is the one that is bundled with the Appveyor build. Below I build from current master, which reproduces the issue. nvim running under the windows terminal supports using When in neovim-qt, typing The problem with this is that it becomes impossible to make a mapping for a single Ctrl + number keypress, as it seems the program is waiting for further input before deciding what to do. I uncommented the keypress debug lines in the source and built with Qt 5.12.8 in Debug mode. Running under QTCreator I get the following output: or, when trying to enter the control character via Ctrl-V: |
|
@dutchgecko Thanks for the detailed description! We should be able to fix this if there isn't platform-specific logic getting in the way...
This was added recently, so if it doesn't work you're on an old version. The version you built from This looks like this is a Windows input bug. I cannot reproduce on Linux. I'm struggling to follow the desired scenario here... Sorry, I am not familiar with or <C-^>. Is the issue that you cannot map It would help me if you write could you write a quick set of repro steps in the following format: Repro Steps:
Observe: X happened but I expected Y. For example, here is what I did to verify on Linux:
Observe: The Don't leave any room for interpretation or configuration differences. Be very explicit. I think getting this working is a matter of massaging the QKeyEvents properly in |
|
Each of the following numbered steps were carried out with a fresh instance of
So, it turns out you can map to ctrl-number, but that ctrl-6 is not mapped to switch buffer by default. That caught me off guard, as the mapping is listed in I realise that the problem I was running into is not the same as the originally posted bug. I'll leave it up to you to decide whether my report is a bug or not. edit: on second thought, I think the interaction with Ctrl-v is unintuitive and might be a bug. |
|
On Linux: Scenarios 1-3 work, Scenario 4 does not work. On Windows: Scenarios 1-4 do not work. Does Scenario 4 work in Here are the Linux's key events don't look right to me either... However I don't know what the input SHOULD be in this case. Since
This smells like a bug to me. So far, I don't see anything preventing us from modifying However, we need to understand the correct way to send these events. What key string does neovim require for this case? |
|
I'm not sure what you mean "scenario x works/does not work". To be clear, scenarios 2 and 4 on windows produce the expected result.
|
|
Good point... Not very clear. Here is a good set of steps that clearly captures the behavior differences:
On Windows/nvim:
On Linux/nvim:
On Windows/nvim-qt:
On Linux/nvim-qt:
Based on these observations, This is definitely a bug, and should be an easy fix. Thanks for helping me reason though this! 👍 |
|
The fix is available in Marking as closed. |
|
This may be worth noting: Translating The only reference related to this I can find is https://sw.kovidgoyal.net/kitty/keyboard-protocol/#legacy-ctrl-mapping-of-ascii-keys. |
Alacritty does not under Windows by default. Not sure about Alacritty on other platforms. You're right that this translation is a feature of the terminal, but since nvim is a terminal program I think it makes sense that a GUI should provide terminal-like behaviour that nvim depends on. In the instance of this bug, typing C-6 sometimes just produced the character '6', which made mapping C-6 to C-^ impossible. |
Hey guys very nice work so far.
I'm having a strange behaviour where I can't switch between current and previous windows buffer from nvim-qt, nvim in terminal works just fine.
There is no CTRL printed when I do the cmd bellow:
:map <C-V><C-6>it gets replaced by just
:map 6Any map using CTRL+NUMBER simple doesn't work; This is a huge problem for me because I'm used to change my buffer by numbers =|
The text was updated successfully, but these errors were encountered: