Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ctrl+j = Ctrl+return for some reason #6912

Closed
Noah-Huppert opened this issue Jul 14, 2020 · 8 comments
Closed

Ctrl+j = Ctrl+return for some reason #6912

Noah-Huppert opened this issue Jul 14, 2020 · 8 comments
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Product-Terminal The new Windows Terminal. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@Noah-Huppert
Copy link

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.

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Jul 14, 2020
@Noah-Huppert
Copy link
Author

Noah-Huppert commented Jul 14, 2020

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
Copy link

eryksun commented Jul 14, 2020

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
Copy link
Member

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

@zadjii-msft zadjii-msft added Area-Input Related to input processing (key presses, mouse, etc.) Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Product-Terminal The new Windows Terminal. labels Jul 14, 2020
@Noah-Huppert
Copy link
Author

Noah-Huppert commented Jul 14, 2020

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

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jul 14, 2020
@DHowett
Copy link
Member

DHowett commented Jul 14, 2020

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
Copy link

ghost commented Jul 14, 2020

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!

@ghost ghost closed this as completed Jul 14, 2020
@ghost ghost added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements Needs-Attention The core contributors need to come back around and look at this ASAP. labels Jul 14, 2020
@Noah-Huppert
Copy link
Author

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

@GiorgosXou
Copy link

GiorgosXou commented Jun 15, 2022

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Input Related to input processing (key presses, mouse, etc.) Product-Terminal The new Windows Terminal. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

5 participants