neovim
neovim copied to clipboard
neovim
Windows: console: <C-2>, <C-/>
A couple control key combos are missing on Windows, notably ^@ which prevents <C-space> mappings.
-
nvim --version: 0.2.2 (still present in 0.3) - Vim (version: 8.1) behaves differently? Yes
- Operating system/version: Win10 17672
- Terminal name/version: conhost
-
$TERM: N/A
Steps to reproduce using nvim -u NORC
Type the following keys in insert mode preceded by <C-v>: <C-2> <C-space> <C-/>
Actual behaviour
<C-2> and <C-/> are not recognized at all, <C-space> is recognized as regular space.
Expected behaviour
The control characters ^@^@^_ are inserted.
There is slightly different behavior between Windows vim and Linux vim/nvim here. On Windows vim, ^_ is not generated when pressing <C-/> (but it can be generated by the _ key still), and <C-space> does not generate ^@, it types a space, but <C-space> itself is mappable. Copying either behavior would probably be fine, although I'd prefer to mimic Linux as it leads to a less complicated vimrc.
Then where do I report this? I’m using the terminal mode programs, and this is clearly supported by conhost.
@parkovski Ah, I guessed wrong then. It helps to mention nvim.exe in the steps to reproduce (instead of nvim-qt.exe).
@parkovski I don't know any terminal where <C-/> does anything, in Vim or otherwise.
Based on https://github.com/libuv/libuv/issues/1958 I guess the other cases are blocked by libuv.
Windows 10 added support for both mapping ctrl-space to ^@ and mapping ctrl-/ to ^_; they're at least in the latest official release (1809/17763) as tested with stock conhost.
@mqudsi It probably will not make sense unless you are using WSL or by setting ENABLE_VIRTUAL_TERMINAL_INPUT and using ReadFile() or ReadConsole(). And libuv tty has not used it(ENABLE_VIRTUAL_TERMINAL_INPUT) yet.
@parkovski Please try the artifacts of #9094. It should correspond to everything to the libuv/libuv#1958 combo keys.
@erw7 Yes, this is under WSL, but they work even when SSH'd into Linux/macOS and running neovim there.
This issue is about Windows native neovim. I do not want to talk about WSL here, because the talk becomes complicated.
Neovim can possibly call SetConsoleMode(..., GetConsoleMode(...) | ENABLE_VIRTUAL_TERMINAL_PROCESSING) itself.
@erw7 That build fixes all the issues except C-Space in a ConPTY (running vim.exe in a WSL tmux window). The ConPTY seems to generate C-Shift-2 (modifiers = Shift | LCtrl, vk = 0x32 '2', UnicodeChar = 0) which is not handled.
@parkovski Sorry to reply late. Thank you for the information. The problem of <C-Space> when executing nvim in WSL can be easily coped with rebuilding libuv with the following patch applied.
diff --git a/src/win/tty.c b/src/win/tty.c
index c8e239c4..9d8ffdaf 100644
--- a/src/win/tty.c
+++ b/src/win/tty.c
@@ -710,7 +710,7 @@ static const char* get_vt100_fn_key(DWORD code, char shift, char ctrl,
VK_CASE(VK_SPACE, NULL, NULL, "\0", NULL) /* <C-Space> => ^@ */
VK_CASE(0x30, NULL, NULL, "0", NULL)
VK_CASE(0x31, NULL, NULL, "1", NULL)
- VK_CASE(0x32, NULL, NULL, "\0", NULL) /* <C-2> => ^@ */
+ VK_CASE(0x32, NULL, "\0", "\0", NULL) /* <C-2> => ^@ */
VK_CASE(0x33, NULL, NULL, "3", NULL)
VK_CASE(0x34, NULL, NULL, "4", NULL)
VK_CASE(0x35, NULL, NULL, "5", NULL)
The comment of input.c in the xterm source code lists several other mappings (contol 3 0x1b, etc). I would like to decide what to do with them together with the problems of this https://github.com/neovim/neovim/pull/9094#issuecomment-429611996. So please wait for a while to change #9094?
It has been roughly 4 years since the issue was created and the issue continues to date. And it's not related to the emulator since I tried already tried switching them (I read somewhere emulator could be the issue).
However, I can confirm that one does not need workarounds anymore to get this working with WSL2. Any chance to get it working with PowerShell/CMD by harnessing the new Windows Terminal some way?
As mentioned in this post, I also highly recommend using neovim-qt on Windows. This allows me to use <C-@> in insert mode with the mapping (on my French keyboard):
inoremap <C-à> <C-@>
which is otherwise impossible with the standard console used by neovim.
I can also use several other Ctrl-Keys mappings.
Can you try the development version?
- The Releases page has pre-built archives for Windows.
- Check
:versionto confirm that you are using the latest version.
The code from nvim v0.8.0-dev+226-g07ade91f2 running under conhost.exe (not from Windows Terminal.app) under WSLv1 on Windows 10 1909 has the following mapping:
- Ctrl-space:
<C-Space> - Ctrl-2:
<C-Space> - Ctrl-/:
^_
If nvim v0.8.0-dev+221-ge501e4ed4 is used as a Windows-native binary (again, started with the system conhost.exe), the following mapping is observed:
- Ctrl-space: no input/not seen
- Ctrl-2: no input/not seen
- Ctrl-/:
^_
So the behavior has changed from the initial report, but is still not where it needs to be. The fact that ctrl-space and ctrl-2 generate no input at all is a step in the right direction, as it means they just need new mappings in the event loop rather than changing an existing, incorrect mapping (going off the fact that they were seen but just processed incorrectly before, so it's not like they're not detectable). The behavior of ctrl-/ seems fine/correct.
Current status is described in https://github.com/neovim/neovim/issues/8435#issuecomment-1128212544 . Please avoid "me too" comments (upvote the issue instead). Send a PR if you have a fix.
Anyone know if there is any update here on the <C-Space> issue on Windows? A lot of plugins still use this keymap in their defaults so I constantly find myself having to remap after forgetting that c-space doesn't work on Windows.
FYI for those who stumble across this, this was a "bug" in Microsoft Windows Terminal and all the details can be found here: https://github.com/microsoft/terminal/issues/15939
Here is the PR with the fix which has not landed in the core terminal release yet on Windows: https://github.com/microsoft/terminal/pull/16298
@GitMurf The bug isn't solely responsible for this, I get this issue without using Microsoft Windows Terminal (I use Wezterm).
@AxiomOfChoices I can confirm that the PR linked didn't solve the issue. The fix landed on WT Preview and I installed latest version of WT Preview, <C-Space> still not working. When using neovim-qt or neovide, the binding works as expected. If there are no remaining causes on WT side, and if @AxiomOfChoices uses Wezterm on Windows, but if it doesn't happen using GUI apps, I think the issue is with Windows itself. Someone mentioned conpty in one of the issues related in terminal's repo and I see conpty is also used in wezterm; so that might be the culprit.
Latest version of Windows Terminal (v1.20.11271.0) also introduced a situation where <C-^> was not working as expected anymore. I was able to fix that defining a custom action in the WT config:
"actions": [
{
"command": {
"action": "sendInput",
"input": "\u001e"
},
"keys": "ctrl+^"
}
],
Cloud this be a viable workaround for <C-Space> and <C-BS> as well? Which unicode would be expected?
Edit: So I tried sending \u0000 which didn't do anything. 😞
@MarcoBuess and anyone experiencing the issue and wants a workaround, using PowerToys (https://learn.microsoft.com/en-us/windows/powertoys/) Keyboard Manager works. I mapped my nvim completion to <C-Y> and mapped keyboard manager from <C-Space> to <C-Y> for WindowsTerminal.exe. Though as a side effect, it requires other terminal related remapping of <C-Space>.
For anyone still struggling with this, this ended up working for me in enabling <C-Space> without any remaps inside the settings.json file:
{
"keys": "ctrl+space",
"command": {
"action": "sendInput",
"input": "\u001b[32;5u"
}
}
@IvanXh0 Are you running in WSL? I'm running outside WSL and the sequence yields " for me.