Ctrl+j = Ctrl+return for some reason

[Noah-Huppert]

Environment

Windows build number: 10.0.18363.0
Windows Terminal version (if applicable): 1.0.1401.0

Any other software? Yes, see below.

I initially saw this behavior in PowerShell 7. However I have reproduced it in cmd.exe as well as the old powershell (powershell.exe compared to the new pwsh.exe).

Since this issue has to do with key chords here is my full Windows Terminal configuration file: https://gist.github.com/Noah-Huppert/6d73079767fcc08edea810cd6beb5a89

One will notice that in an effort to isolate the cause of this bug I have unbound every command that was in the default.json keybindings section except for copy and paste.

Steps to reproduce

1. Open Windows Terminal with PowerShell 7
2. Enter the following command to see what key is being pressed:

   [console]::ReadKey()

3. Press Ctrl+j (Press and hold down the control key (left or right) and then press and hold down the "j" key. Then release both keys.)

Expected behavior

The key chord sent to the shell should be J with a Control modifier. The ReadKey() command should return:

KeyChar Key Modifiers
------- --- ---------

   J   Control

Actual behavior

The key chord sent to the shell is Enter. The ReadKey() command returns:

KeyChar   Key Modifiers
-------   --- ---------
      … Enter   Control

This behavior only occurs in Windows Terminal. If I open up Powershell 7 in the Cmder terminal emulator the expected behavior occurs. The behavior described here in the actual behavior section seems to only occur in Windows Terminal on my machine.

This behavior occurs in any application running within Windows Terminal. Which is what has led me to believe that this is an issue with Windows Terminal and not something else. I initially saw this behavior in Emacs where it kept saying C-<return> was not bound to any commands when I would press C-j. I tested Emacs in powershell.exe and cmd.exe within Windows Terminal and was able to reproduce the bug. Making me confident that pwsh.exe nor powershell.exe nor cmd.exe are causing the issue. The steps to reproduce above are a minimal reproducible example. I write this paragraph only to show that this issue does not have to do with any specifics of how the PowerShell [console]::ReadKey() works.

[Noah-Huppert]

I do have emacs mode enabled in powershell which these issues talk about: #3890 and #879.

However I don't think this is a duplicate or related to PSReadline because even in cmd.exe the problem occurs.

[eryksun]

I took a look at the result of PowerShell's ReadConsoleInputW calls for ReadKey() and Ctrl+J when running with a console session provided by conhost.exe vs. a session provided by openconsole.exe under Windows Terminal.

conhost.exe:

struct _KEY_EVENT_RECORD
   +0x000 bKeyDown         : 0n1
   +0x004 wRepeatCount     : 1
   +0x006 wVirtualKeyCode  : 0x4a
   +0x008 wVirtualScanCode : 0x24
   +0x00a uChar            : _KEY_EVENT_RECORD::<unnamed-type-uChar>
   +0x00c dwControlKeyState : 8

union _KEY_EVENT_RECORD::<unnamed-type-uChar>
   +0x000 UnicodeChar      : 0xa ''
   +0x000 AsciiChar        : 10 ''

openconsole.exe:

struct _KEY_EVENT_RECORD
   +0x000 bKeyDown         : 0n1
   +0x004 wRepeatCount     : 1
   +0x006 wVirtualKeyCode  : 0xd
   +0x008 wVirtualScanCode : 0x1c
   +0x00a uChar            : _KEY_EVENT_RECORD::<unnamed-type-uChar>
   +0x00c dwControlKeyState : 8

union _KEY_EVENT_RECORD::<unnamed-type-uChar>
   +0x000 UnicodeChar      : 0xa ''
   +0x000 AsciiChar        : 10 ''

It's the same LF (U+000A) Unicode character in each case. But the virtual-key code from conhost.exe is 0x4A ("J"), while openconsole.exe under Windows Terminal returns 0xD (VK_RETURN).

[zadjii-msft]

This is probably caused by conpty arbitrarily picking one of the two keys. I bet this is better on Terminal Preview, 1.1+. Could you verify for me?

For more info, check out #4999

[Noah-Huppert]

@zadjii-msft You would be correct. On Windows Terminal 1.1.1812.0:

% [console]::ReadKey()


KeyChar Key Modifiers
------- --- ---------
      …   J   Control

And key combinations which use Ctrl+j work in Emacs as well. 😄

[DHowett]

Root cause is that there is no encoding for ^J in VT that is different from that of Ctrl+Enter. This is true of all non-Windows terminals. xterm is worse: it treats Ctrl+Enter as ^M by default.

It just so happens that Windows once let people get more info than that.

/dup #4999

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[Noah-Huppert]

Thanks Microsoft Terminal team for such a switch response and resolution 👍

[GiorgosXou]

It is both a bug and a feature