Windows: console: <C-2>, <C-/>

[parkovski]

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.

[justinmk]

@parkovski I don't know any terminal where <C-/> does anything, in Vim or otherwise.

Based on libuv/libuv#1958 I guess the other cases are blocked by libuv.

[mqudsi]

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.

[erw7]

@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.

[mqudsi]

@erw7 Yes, this is under WSL, but they work even when SSH'd into Linux/macOS and running neovim there.

[erw7]

This issue is about Windows native neovim. I do not want to talk about WSL here, because the talk becomes complicated.

[mqudsi]

Neovim can possibly call SetConsoleMode(..., GetConsoleMode(...) | ENABLE_VIRTUAL_TERMINAL_PROCESSING) itself.

[parkovski]

@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.

[erw7]

@parkovski Sorry to reply late. Thank you for the information. The problem of 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 #9094 (comment). So please wait for a while to change #9094?

[parkovski]

I've been using this libuv patch for a while, and have not had any issues with windows keys since.

[justinmk]

Can you try the development version?

• The Releases page has pre-built archives for Windows.
• Check :version to confirm that you are using the latest version.

[mqudsi]

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.

[justinmk]

Current status is described in #8435 (comment) . Please avoid "me too" comments (upvote the issue instead). Send a PR if you have a fix.

[GitMurf]

FYI for those who stumble across this, this was a "bug" in Microsoft Windows Terminal and all the details can be found here: microsoft/terminal#15939

Here is the PR with the fix which has not landed in the core terminal release yet on Windows: microsoft/terminal#16298

[AxiomOfChoices]

@GitMurf The bug isn't solely responsible for this, I get this issue without using Microsoft Windows Terminal (I use Wezterm).

[MarcoBuess]

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. 😞

[kulkalkul]

@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>.

[IvanXh0]

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"
            }
        }
       

[MarcoBuess]

@IvanXh0 Are you running in WSL? I'm running outside WSL and the sequence yields " for me.