Ctrl Key Not Working in Vim over SSH with Specific Terminal Software

[waterexit]

Prerequisites

• [x] Write a descriptive title.
• [x] Make sure you are able to repro it on the latest version
• [x] Search the existing issues.

Introduction

I am using terminals like Wezterm and Xterm on Ubuntu to connect to Windows via SSH. The default shell in this setup is WSL. However, upon starting Vim, none of the operations involving the Ctrl key, such as Ctrl+W and Ctrl+R, work. The keys Ctrl+C and Ctrl+Z function perfectly in the Bash shell, so this issue appears to occur only when Vim is launched.

Interestingly, this issue doesn't occur when using gnome-terminal.

Additionally, when using the Using terminals like wezterm and xterm to connect to an Ubuntu system via SSH, the problem does not occur. Honestly, I'm not sure if this is an issue with Win32-OpenSSH that needs fixing, but I'm interested to know why this happens.

Expected behavior

Control key should work in Vim while using Wezterm or Xterm.

Actual behavior

Control key does not work in Vim while using Wezterm or Xterm.

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.19041.5369
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.5369
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version

OpenSSH_for_Windows_9.8p1 Win32-OpenSSH-GitHub, LibreSSL 3.9.2

[tgauth]

The default shell in this setup is WSL.

How are you configuring WSL as the default shell?

Also, have you tested with previous versions of OpenSSH, like v9.5? Curious if this is a regression in 9.8 or something that has not worked previously either.

[StevenBucher98]

I would also be curious if you see this happen when WSL is not the default shell, in case it is getting in the way of some previously used keybindings.

[waterexit]

First of all, thank you for your response.

How are you configuring WSL as the default shell?

I configured it using the following command.

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\system32\bash.exe" -PropertyType String -Force

I would also be curious if you see this happen when WSL is not the default shell, in case it is getting in the way of some previously used keybindings.

However, after setting PowerShell as the default shell, it seems that the same issue occurs even when I open WSL with the wsl command and then open vim.

Additionally, when I open the Windows version of vim from PowerShell connected via SSH, the Ctrl key seems to function correctly.

Also, have you tested with previous versions of OpenSSH, like v9.5? Curious if this is a regression in 9.8 or something that has not worked previously either.

I downgraded to version 9.5 and tested it, but the same issue occurred.

[StevenBucher98]

@waterexit just to confirm this is all using the Wezterm and Xterm Terminals? I want to rule out that this is not an issue caused by either of these programs.

[mgkuhn]

Can you test a much longer list of Ctrl-keystrokes, and report which ones work and which ones don't?

What does stty -a report?

Are the emacs-style Ctrl-key functions that the bash command-line editor implements working?

Are the control-keys in emacs working?

Are you seeing any unexpected characters appear on the screen when you send a Ctrl code?

Note that the Ctrl-key on its own isn't sending any bytes via the channel. All that the control key does is to subtract 64 (0x40) from the ASCII byte that the keyboard sends for the other key that you press. Something may be intercepting some of those other control-bytes in the range 0-31 (Ctrl-@ to Ctrl-_), and it would be useful to know which bytes don't get through intact.

[mgkuhn]

Does at least Ctrl-J still behave in the same way as the return key? (Both should output the same byte LF = 'J'−64 = 10.)

Likewise Ctrl-[ should behave the same way as ESC.