starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Arrow Keys in vim within Git-bash stopped working. #9354

New Issue
Closed
opened 2026-01-31 01:52:28 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 01:52:28 +00:00
Owner
Copy Link

Originally created by @camckee on GitHub (Jun 30, 2020).

Issue

The arrow keys stopped working in vim with the latest version of the Windows Terminal. Whenever I press an arrow key, the screen flickers a blue, and nothing happens. I have to hold the control key down before the arrow keys work. Vim in git-bash worked just fine until the latest update. Vim still works in PowerShell.

Environment

Windows build number: 10.0.18363.0 Microsoft Windows NT 10.0.18363.0
Windows Terminal version (if applicable):  1.0.1811.0
Git for Windows: git version 2.27.0.windows.1 - Default Configuration.

Steps to reproduce

Here is my configuration for Git-Bash.

    {
      "guid": "{D1F7F53F-EC3D-4511-A67E-EF4F97E36AC6}",
      "acrylicOpacity": 0.90,
      "closeOnExit": true,
      "colorScheme": "Campbell",
      "commandline": "\"%PROGRAMFILES%\\git\\usr\\bin\\bash.exe\" -l -i",
      "cursorColor": "#FFFFFF",
      "cursorShape": "bar",
      "fontFace": "Consolas",
      "historySize": 9001,
      "icon": "%SystemDrive%\\Program Files\\Git\\mingw64\\share\\git\\git-for-windows.ico",
      "name": "Git Bash",
      "padding": "0, 0, 0, 0",
      "snapOnInput": true,
      "startingDirectory": "%USERPROFILE%",
      "useAcrylic": true
    }
  1. Open a new terminal window.
  2. Execute "vim ."
  3. Push the down arrow to select a file. Notice the cursor does not move.

Expected behavior

The cursor should move based on the arrow key pressed.

Actual behavior

The screen flickers blue and the cursor remains in the same position.

Originally created by @camckee on GitHub (Jun 30, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Issue The arrow keys stopped working in vim with the latest version of the Windows Terminal. Whenever I press an arrow key, the screen flickers a blue, and nothing happens. I have to hold the control key down before the arrow keys work. Vim in git-bash worked just fine until the latest update. Vim still works in PowerShell. # Environment ```none Windows build number: 10.0.18363.0 Microsoft Windows NT 10.0.18363.0 Windows Terminal version (if applicable): 1.0.1811.0 Git for Windows: git version 2.27.0.windows.1 - Default Configuration. ``` # Steps to reproduce Here is my configuration for Git-Bash. ``` { "guid": "{D1F7F53F-EC3D-4511-A67E-EF4F97E36AC6}", "acrylicOpacity": 0.90, "closeOnExit": true, "colorScheme": "Campbell", "commandline": "\"%PROGRAMFILES%\\git\\usr\\bin\\bash.exe\" -l -i", "cursorColor": "#FFFFFF", "cursorShape": "bar", "fontFace": "Consolas", "historySize": 9001, "icon": "%SystemDrive%\\Program Files\\Git\\mingw64\\share\\git\\git-for-windows.ico", "name": "Git Bash", "padding": "0, 0, 0, 0", "snapOnInput": true, "startingDirectory": "%USERPROFILE%", "useAcrylic": true } ``` 1. Open a new terminal window. 2. Execute "vim ." 3. Push the down arrow to select a file. Notice the cursor does not move. # Expected behavior The cursor should move based on the arrow key pressed. # Actual behavior The screen flickers blue and the cursor remains in the same position. <!-- What's actually happening? -->
claunia added the Resolution-Duplicate label 2026-01-31 01:52:28 +00:00
claunia commented 2026-01-31 01:52:29 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jul 1, 2020):

Reproduced with Windows Terminal 1.0.1811.0.
However, Windows Terminal Preview 1.1.1812.0 does not have this problem.

@KalleOlaviNiemitalo commented on GitHub (Jul 1, 2020): Reproduced with Windows Terminal 1.0.1811.0. However, Windows Terminal Preview 1.1.1812.0 does not have this problem.
claunia commented 2026-01-31 01:52:29 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jul 1, 2020):

The problem also affects less. There, it seems less is getting ESC [ B rather than the expected ESC O B. https://github.com/microsoft/terminal/issues/6626 had similar symptoms but I have not checked whether ENABLE_VIRTUAL_TERMINAL_INPUT is being lost in Windows Terminal 1.0.1811.0.

@KalleOlaviNiemitalo commented on GitHub (Jul 1, 2020): The problem also affects `less`. There, it seems `less` is getting ESC \[ B rather than the expected ESC O B. <https://github.com/microsoft/terminal/issues/6626> had similar symptoms but I have not checked whether `ENABLE_VIRTUAL_TERMINAL_INPUT` is being lost in Windows Terminal 1.0.1811.0.
claunia commented 2026-01-31 01:52:29 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jul 2, 2020):

less gets ESC [ B as characters from ReadConsoleInputW. The console input handle has mode 0x209 = ENABLE_PROCESSED_INPUT | ENABLE_WINDOW_INPUT | ENABLE_VIRTUAL_TERMINAL_INPUT during this call.

It seems DECCKM does not always take effect, but I can't make sense of why.

I made a test program that

  1. Displays the current console modes.
  2. Disables the console input modes ENABLE_ECHO_INPUT | ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT | ENABLE_MOUSE_INPUT | ENABLE_WINDOW_INPUT.
  3. Enables the console input mode ENABLE_VIRTUAL_TERMINAL_INPUT.
  4. Enables the console output mode ENABLE_VIRTUAL_TERMINAL_PROCESSING.
  5. Loops calling ReadConsoleInputW and displaying the results until Ctrl+C is pressed.
  6. Restores the console modes.

Windows Terminal Preview 1.1.1812.0

When I start a Git Bash profile in Windows Terminal Preview 1.1.1812.0, run the program there, and press the Down arrow key, it outputs:

Old console input mode: 0xf
Old console output mode: 0x3
New console input mode: 0x200
New console output mode: 0x7
Press Ctrl+C to exit.
ReadConsoleInput returned 3 input records:
[0] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x1b, cks=0
[1] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x5b, cks=0
[2] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x42, cks=0
ReadConsoleInput returned 1 input records:
[0] = KEY_EVENT: kd=0, rc=1, vkc=0x28, vsk=0x50, uc=0, cks=0
ReadConsoleInput returned 1 input records:
[0] = KEY_EVENT: kd=1, rc=1, vkc=0x11, vsk=0x1d, uc=0, cks=0x4
ReadConsoleInput returned 1 input records:
[0] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x3, cks=0
Restoring console modes.
Exiting.

That is, the ENABLE_VIRTUAL_TERMINAL_PROCESSING mode was originally disabled, and the Down arrow key was translated to ESC [ B.

I run printf "\033[?1h" in Bash and run the test program again and press Down. The output is the same except now Down is translated to ESC O B, as expected.

I run less /etc/package-versions.txt and press q to exit, then run the test program again. The Down arrow key is translated to ESC [ B again, indicating that less disabled Cursor Keys Application Mode when exiting.

Windows Terminal 1.0.1811.0

When trying the same steps in Windows Terminal 1.0.1811.0, the first difference is that the Ctrl key does not generate any INPUT_RECORD even though the console modes are the same as in Windows Terminal Preview. That can't be the cause of the problem, though. The Down arrow key is translated to ESC [ B, like in Windows Terminal Preview.

After printf "\033[?1h", the test program shows that the Down arrow key is still translated to ESC [ B, even though it should now be ESC O B.

I debug bash.exe and see that printf "\033[?1h" outputs the control sequence by calling WriteConsoleW and enables the ENABLE_VIRTUAL_TERMINAL_PROCESSING console output mode before that call. I add a similar WriteConsoleW(hConsoleOutput, L"\033[?1h", 5, &numberOfCharsWritten, NULL) call to the test program, after the SetConsoleMode calls. There, the control sequence enables Cursor Keys Application Mode just fine.

After Cursor Keys Application Mode has been enabled by the test program, less /etc/package-versions.txt also gets the application-mode sequences that it expects. Strangely, Cursor Keys Application Mode remains enabled after less exits, or after I run tput rmkx.

@KalleOlaviNiemitalo commented on GitHub (Jul 2, 2020): `less` gets ESC \[ B as characters from ReadConsoleInputW. The console input handle has mode 0x209 = ENABLE_PROCESSED_INPUT | ENABLE_WINDOW_INPUT | ENABLE_VIRTUAL_TERMINAL_INPUT during this call. It seems DECCKM does not always take effect, but I can't make sense of why. --- I made a test program that 1. Displays the current console modes. 2. Disables the console input modes ENABLE_ECHO_INPUT | ENABLE_LINE_INPUT | ENABLE_PROCESSED_INPUT | ENABLE_MOUSE_INPUT | ENABLE_WINDOW_INPUT. 3. Enables the console input mode ENABLE_VIRTUAL_TERMINAL_INPUT. 4. Enables the console output mode ENABLE_VIRTUAL_TERMINAL_PROCESSING. 5. Loops calling ReadConsoleInputW and displaying the results until Ctrl+C is pressed. 6. Restores the console modes. ## Windows Terminal Preview 1.1.1812.0 When I start a Git Bash profile in Windows Terminal Preview 1.1.1812.0, run the program there, and press the Down arrow key, it outputs: ``` Old console input mode: 0xf Old console output mode: 0x3 New console input mode: 0x200 New console output mode: 0x7 Press Ctrl+C to exit. ReadConsoleInput returned 3 input records: [0] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x1b, cks=0 [1] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x5b, cks=0 [2] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x42, cks=0 ReadConsoleInput returned 1 input records: [0] = KEY_EVENT: kd=0, rc=1, vkc=0x28, vsk=0x50, uc=0, cks=0 ReadConsoleInput returned 1 input records: [0] = KEY_EVENT: kd=1, rc=1, vkc=0x11, vsk=0x1d, uc=0, cks=0x4 ReadConsoleInput returned 1 input records: [0] = KEY_EVENT: kd=1, rc=1, vkc=0, vsk=0, uc=0x3, cks=0 Restoring console modes. Exiting. ``` That is, the ENABLE_VIRTUAL_TERMINAL_PROCESSING mode was originally disabled, and the Down arrow key was translated to ESC \[ B. I run `printf "\033[?1h"` in Bash and run the test program again and press Down. The output is the same except now Down is translated to ESC O B, as expected. I run `less /etc/package-versions.txt` and press `q` to exit, then run the test program again. The Down arrow key is translated to ESC \[ B again, indicating that `less` disabled Cursor Keys Application Mode when exiting. ## Windows Terminal 1.0.1811.0 When trying the same steps in Windows Terminal 1.0.1811.0, the first difference is that the Ctrl key does not generate any INPUT_RECORD even though the console modes are the same as in Windows Terminal Preview. That can't be the cause of the problem, though. The Down arrow key is translated to ESC \[ B, like in Windows Terminal Preview. After `printf "\033[?1h"`, the test program shows that the Down arrow key is still translated to ESC \[ B, even though it should now be ESC O B. I debug `bash.exe` and see that `printf "\033[?1h"` outputs the control sequence by calling WriteConsoleW and enables the ENABLE_VIRTUAL_TERMINAL_PROCESSING console output mode before that call. I add a similar `WriteConsoleW(hConsoleOutput, L"\033[?1h", 5, &numberOfCharsWritten, NULL)` call to the test program, after the SetConsoleMode calls. There, the control sequence enables Cursor Keys Application Mode just fine. After Cursor Keys Application Mode has been enabled by the test program, `less /etc/package-versions.txt` also gets the application-mode sequences that it expects. Strangely, Cursor Keys Application Mode remains enabled after `less` exits, or after I run `tput rmkx`.
claunia commented 2026-01-31 01:52:30 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 2, 2020):

From the Terminal's perspective, ENABLE_VIRTUAL_TERMINAL_INPUT is always on. It can't be lost/forgotten, because the terminal only generates VT. In general, it always has conhost sitting between it and the application to do translation from VT input. There are cases when the conhost sitting in the middle enters passthrough mode and dumps input straight out of terminal into the application.
Therefore, Terminal needs to be aware of DECCKM. Whether it receives DECCKM and therefore whether it generates the right cursor keys, however, is based on whether the application has requested ENABLE_VIRTUAL_TERMINAL_INPUT.
(There are applications that ask for DECCKM or other VT input format changes but are not in VT input mode, and sending them that data will freak them out.)

For WT 1.0, here's the matrix of behaviors.

ActionVT Output ModeVT Input ModeNotes
Application prints \e[?1h ❌ ❌ VT output is off, request ignored
❌ ✅
✅ ❌ conhost (PTY) (only) enables DECCKM
✅ ✅ conhost (PTY) _and Terminal_ enable DECCKM
ActionVT Output ModeVT Input ModePTY in DECCKM modeTerminal in DECCKM modeNotes
User presses arrow key ❌ ❌ ❌ ❌ Terminal emits \e[A or \eOA
conhost (PTY) translates it into KEY_EVENT_RECORD
✅ ❌ ✅ ❌ Terminal emits \e[A
conhost (PTY) translates it into KEY_EVENT_RECORD
✅ ❌ ✅ ✅ Terminal emits \eOA
conhost (PTY) translates it into KEY_EVENT_RECORD
✅ ✅ passthrough mode ❌ Terminal emits \e[A
conhost (PTY) passes it through unmodified
❌ ✅ ❌
✅ ✅ ✅ Terminal emits \eOA
conhost (PTY) passes it through unmodified
❌ ✅ ✅
BEHAVIORS BEFORE TERMINAL 1.0
ActionVT Output ModeVT Input ModeNotes
Application prints \e[?1h ❌ ❌ VT output is off, request ignored
❌ ✅
✅ ❌ conhost (PTY) (only) enables DECCKM
✅ ✅
ActionVT Output ModeVT Input ModePTY in DECCKM modeNotes
User presses arrow key ❌ ❌ ignored Terminal emits \e[A
conhost (PTY) translates it into KEY_EVENT_RECORD
✅ ❌
❌ ✅ ❌ Terminal emits \e[A
conhost (PTY) translates it into \e[A
✅ ✅ ❌
❌ ✅ ✅ Terminal emits \e[A
conhost (PTY) translates it into \e[OA
✅ ✅ ✅
@DHowett commented on GitHub (Jul 2, 2020): From the Terminal's perspective, `ENABLE_VIRTUAL_TERMINAL_INPUT` is always on. It can't be lost/forgotten, because the terminal only generates VT. In general, it always has conhost sitting between it and the application to do translation from VT input. There are cases when the conhost sitting in the middle enters passthrough mode and dumps input straight out of terminal into the application. Therefore, Terminal needs to be aware of DECCKM. Whether it receives `DECCKM` and therefore whether it _generates the right cursor keys_, however, is based on whether the application has requested `ENABLE_VIRTUAL_TERMINAL_INPUT`. (There are applications that ask for DECCKM or other VT input format changes but are _not in VT input mode_, and sending them that data will freak them out.) For WT 1.0, here's the matrix of behaviors. <table><tbody> <tr><th>Action</th><th>VT Output Mode</th><th>VT Input Mode</th><th>Notes</th></tr> <tr> <td rowspan="4">Application prints <code>\e[?1h</code></td> <td>❌</td> <td>❌</td> <td rowspan="2">VT output is off, request ignored</td> </tr> <tr> <td>❌</td> <td>✅</td> <!-- rowspanned --> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>❌</td> <td>conhost (PTY) (only) enables DECCKM</td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>✅</td> <td>conhost (PTY) _and Terminal_ enable DECCKM</td> </tr> </tbody></table> <table><tbody> <tr><th>Action</th><th>VT Output Mode</th><th>VT Input Mode</th><th>PTY in DECCKM mode</th><th>Terminal in DECCKM mode</th><th>Notes</th></tr> <tr> <td rowspan="8">User presses arrow key</td> <td>❌</td> <td>❌</td> <td>❌</td> <td>❌</td> <td>Terminal emits <code>\e[A</code> or <code>\eOA</code><br>conhost (PTY) translates it into KEY_EVENT_RECORD</td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>❌</td> <td>✅</td> <td>❌</td> <td>Terminal emits <code>\e[A</code><br>conhost (PTY) translates it into KEY_EVENT_RECORD</td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>❌</td> <td>✅</td> <td>✅</td> <td>Terminal emits <code>\eOA</code><br>conhost (PTY) translates it into KEY_EVENT_RECORD</td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>✅</td> <td rowspan="4"><em>passthrough mode</em></td> <td>❌</td> <td rowspan="2">Terminal emits <code>\e[A</code><br>conhost (PTY) <b>passes it through unmodified</b></td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>❌</td> <td>✅</td> <!-- rowspanned --> <td>❌</td> <!-- rowspanned --> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>✅</td> <!-- rowspanned --> <td>✅</td> <td rowspan="2">Terminal emits <code>\eOA</code><br>conhost (PTY) <b>passes it through unmodified</b></td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>❌</td> <td>✅</td> <!-- rowspanned --> <td>✅</td> <!-- rowspanned --> </tr> </tbody></table> <details> <summary>BEHAVIORS BEFORE TERMINAL 1.0</summary> <table><tbody> <tr><th>Action</th><th>VT Output Mode</th><th>VT Input Mode</th><th>Notes</th></tr> <tr> <td rowspan="4">Application prints <code>\e[?1h</code></td> <td>❌</td> <td>❌</td> <td rowspan="2">VT output is off, request ignored</td> </tr> <tr> <td>❌</td> <td>✅</td> <!-- rowspanned --> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>❌</td> <td rowspan="2">conhost (PTY) (only) enables DECCKM</td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>✅</td> <!-- rowspanned --> </tr> </tbody></table> <table><tbody> <tr><th>Action</th><th>VT Output Mode</th><th>VT Input Mode</th><th>PTY in DECCKM mode</th><th>Notes</th></tr> <tr> <td rowspan="8">User presses arrow key</td> <td>❌</td> <td>❌</td> <td rowspan="2"><em>ignored</em></td> <td rowspan="2">Terminal emits <code>\e[A</code><br>conhost (PTY) translates it into KEY_EVENT_RECORD</td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>❌</td> <!-- rowspanned --> <!-- rowspanned --> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>❌</td> <td>✅</td> <td>❌</td> <td rowspan="2">Terminal emits <code>\e[A</code><br>conhost (PTY) translates it into <code>\e[A</code></td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>✅</td> <td>❌</td> <!-- rowspanned --> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>❌</td> <td>✅</td> <td>✅</td> <td rowspan="2">Terminal emits <code>\e[A</code><br>conhost (PTY) translates it into <code>\e[OA</code></td> </tr> <tr> <!--<td rowspan="1">Application prints `\e[?1h`</td>--> <td>✅</td> <td>✅</td> <td>✅</td> <!-- rowspanned --> </tr> </tbody></table> </details>
claunia commented 2026-01-31 01:52:30 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 2, 2020):

Okay, I'm literally seeing this behavior at the PTY:

  • Input Mode = 0x9
  • Input Mode = 0x209
  • Input Mode = 0x9
  • Print out DECCKM
  • Input Mode = 0x209
  • Input Mode = 0x9

This happens with printf, this happens with less's startup (though it prints more than just DECCKM)`, this happens pretty much every time I launch a process.

It's quite literally disabling VT input mode only while it is changing the input configuration. If we'd ever made the console more strict ("VT input mode changes only apply when VT input mode is on"), this would break horribly. I wonder why they'd do this?

@DHowett commented on GitHub (Jul 2, 2020): Okay, I'm literally seeing this behavior at the PTY: * Input Mode = 0x9 * Input Mode = 0x209 * Input Mode = 0x9 * Print out `DECCKM` * Input Mode = 0x209 * Input Mode = 0x9 This happens with `printf`, this happens with less's startup (though it prints more than just DECCKM)`, this happens pretty much every time I launch a process. It's quite literally disabling VT input mode _only while it is changing the input configuration_. If we'd ever made the console more strict ("VT input mode changes only apply when VT input mode is on"), this would break horribly. I wonder why they'd do this?
claunia commented 2026-01-31 01:52:30 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 2, 2020):

This regressed with #6485, which was done explicitly because OpenSSH requests mouse mode when it cannot possibly receive mouse input. We cannot live in a world where we support both of these insane uses of the console API 😄

@DHowett commented on GitHub (Jul 2, 2020): This regressed with #6485, which was done explicitly because OpenSSH requests mouse mode when it cannot possibly receive mouse input. We cannot live in a world where we support both of these insane uses of the console API :smile:
claunia commented 2026-01-31 01:52:30 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Jul 3, 2020):

Whether it receives DECCKM and therefore whether it generates the right cursor keys, however, is based on whether the application has requested ENABLE_VIRTUAL_TERMINAL_INPUT.

I totally did not expect that. If ENABLE_VIRTUAL_TERMINAL_INPUT is designed to affect which control sequences a pseudoconsole forwards from WriteConsole to the terminal, it is worth documenting.

This regressed with #6485

Why doesn't Windows Terminal Preview 1.1.1812.0 have the same problem, then? https://github.com/microsoft/terminal/commit/6ff8ba772890bf8abb8431295fe97c8e9e280dcb was cherry-picked from https://github.com/microsoft/terminal/commit/5e2c4c66e3dcb66c9d60769a2a028e39711168fd, which is included in that version.

@KalleOlaviNiemitalo commented on GitHub (Jul 3, 2020): > Whether it receives `DECCKM` and therefore whether it _generates the right cursor keys_, however, is based on whether the application has requested `ENABLE_VIRTUAL_TERMINAL_INPUT`. I totally did not expect that. If `ENABLE_VIRTUAL_TERMINAL_INPUT` is designed to affect which control sequences a pseudoconsole forwards from `WriteConsole` to the terminal, it is worth documenting. > This regressed with #6485 Why doesn't Windows Terminal Preview 1.1.1812.0 have the same problem, then? <https://github.com/microsoft/terminal/commit/6ff8ba772890bf8abb8431295fe97c8e9e280dcb> was cherry-picked from <https://github.com/microsoft/terminal/commit/5e2c4c66e3dcb66c9d60769a2a028e39711168fd>, which is included in that version.
claunia commented 2026-01-31 01:52:30 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 8, 2020):

So, this is where it gets interesting. Windows Terminal 1.1+ was cut after #4999 landed. When that mode is engaged, it actually doesn't matter what mode terminal thinks is on at all. It just funnels raw keyboard events into the conhost backing the tab and the conhost's decision on how to encode them is "final."

Instead of \e[C or \eOC, we get... ␛[39;77;0;1;0;1_ ␛[39;77;0;0;0;1_.

@DHowett commented on GitHub (Jul 8, 2020): So, this is where it gets interesting. Windows Terminal 1.1+ was cut after #4999 landed. When _that_ mode is engaged, it actually doesn't matter what mode _terminal_ thinks is on at all. It just funnels raw keyboard events into the conhost backing the tab and the conhost's decision on how to encode them is "final." Instead of `\e[C` or `\eOC`, we get... `␛[39;77;0;1;0;1_` `␛[39;77;0;0;0;1_`.
claunia commented 2026-01-31 01:52:31 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 10, 2020):

So, this is going to resolve itself for terminal when 1.1 goes stable (which is soon). It's going to become more of a problem for other terminals (alacritty, hyper, vscode, etc., even wsl-in-wsl) once this change flows up and out through Windows. Because of that, I'm going to transform this issue to match what I believe needs to be done to fix it.

@DHowett commented on GitHub (Jul 10, 2020): So, this is going to resolve itself for _terminal_ when 1.1 goes stable (which is soon). It's going to become more of a problem for other terminals (alacritty, hyper, vscode, etc., even wsl-in-wsl) once this change flows up and out through Windows. Because of that, I'm going to transform this issue to match what I believe needs to be done to fix it.
claunia commented 2026-01-31 01:52:31 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jul 10, 2020):

/dup #6859

@DHowett commented on GitHub (Jul 10, 2020): /dup #6859
claunia commented 2026-01-31 01:52:31 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 10, 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 commented on GitHub (Jul 10, 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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9354
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?