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

cream for vim (< 7.4.827) when run from Windows Terminal seems to get the wrong key codes #819

New Issue
Closed
opened 2026-01-30 22:05:23 +00:00 by claunia · 14 comments
claunia commented 2026-01-30 22:05:23 +00:00
Owner
Copy Link

Originally created by @binarycrusader on GitHub (May 8, 2019).

  • Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.18362.86]

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

vim /some/large/document.txt
Ctrl+F
Ctrl+B

  • What's wrong / what should be happening instead:

Ctrl+F should cause page down
Ctrl+B should cause page up

These work fine in existing cmd, powershell, etc. but don't work as expected in Terminal.

vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 3 2014 09:06:12)
MS-Windows 32-bit console version
Included patches: 1-493

(I believe I installed the above through chocolatey at some point.)

Originally created by @binarycrusader on GitHub (May 8, 2019). * Your Windows build number: (Type `ver` at a Windows Command Prompt) Microsoft Windows [Version 10.0.18362.86] * What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots) vim /some/large/document.txt Ctrl+F Ctrl+B * What's wrong / what should be happening instead: Ctrl+F should cause page down Ctrl+B should cause page up These work fine in existing cmd, powershell, etc. but don't work as expected in Terminal. vim --version VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 3 2014 09:06:12) MS-Windows 32-bit console version Included patches: 1-493 (I believe I installed the above through chocolatey at some point.)
claunia added the Issue-BugArea-InputResolution-ExternalProduct-Terminal labels 2026-01-30 22:05:23 +00:00
claunia commented 2026-01-30 22:05:24 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 8, 2019):

Could you run showkey -a and press ctrl+B and Ctrl+F, and paste what it outputs?

You should see something like this:
image

@zadjii-msft commented on GitHub (May 8, 2019): Could you run `showkey -a` and press ctrl+B and Ctrl+F, and paste what it outputs? You should see something like this: ![image](https://user-images.githubusercontent.com/18356694/57381665-f740b680-7170-11e9-84b3-c0d5dd5c27ee.png)
claunia commented 2026-01-30 22:05:25 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

Could you run showkey -a and press ctrl+B and Ctrl+F, and paste what it outputs?

You should see something like this:

Where is the showkey utility? How do I obtain it?

Note that I'm running the win32 native version of vim -- not a wsl version.

@binarycrusader commented on GitHub (May 8, 2019): > Could you run `showkey -a` and press ctrl+B and Ctrl+F, and paste what it outputs? > > You should see something like this: Where is the showkey utility? How do I obtain it? Note that I'm running the win32 native version of vim -- not a wsl version.
claunia commented 2026-01-30 22:05:25 +00:00
Author
Owner
Copy Link

@caksoylar commented on GitHub (May 8, 2019):

I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from here.

@caksoylar commented on GitHub (May 8, 2019): I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from [here](https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1099).
claunia commented 2026-01-30 22:05:25 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 8, 2019):

Oh. That's certainly curious.

Yea showkey is a linux util.

I don't know too much about Windows vim, so I'll loop in our resident expert, @DHowett-MSFT.

From what I'm reading, you might be able to :set showcmd in vim, to have it briefly display each keystroke in the status line. Could you try that and see what it outputs? For me it very briefly flashes ^F and ^B near the bottom right of the window.

@zadjii-msft commented on GitHub (May 8, 2019): Oh. That's certainly curious. Yea `showkey` is a linux util. I don't know too much about Windows vim, so I'll loop in our resident expert, @DHowett-MSFT. From what I'm reading, you might be able to `:set showcmd` in vim, to have it briefly display each keystroke in the status line. Could you try that and see what it outputs? For me it *very* briefly flashes `^F` and `^B` near the bottom right of the window.
claunia commented 2026-01-30 22:05:25 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

showcmd doesn't show anything, and if I use vim -w to have it record the keystrokes to the file, it doesn't show that those keystrokes were received at all.

I'm using a MS modern keyboard with the fingerprint reader with en-US as input language, so nothing particularly unusual.

The problem reproduces easily in cmd and powershell tabs in the new Windows Terminal, but not anywhere else.

Can you point me at where keyboard input is handled for the Terminal? (Basically, where it gets passed on to the program?)

@binarycrusader commented on GitHub (May 8, 2019): showcmd doesn't show anything, and if I use vim -w to have it record the keystrokes to the file, it doesn't show that those keystrokes were received at all. I'm using a MS modern keyboard with the fingerprint reader with en-US as input language, so nothing particularly unusual. The problem reproduces easily in cmd and powershell tabs in the new Windows Terminal, but not anywhere else. Can you point me at where keyboard input is handled for the Terminal? (Basically, where it gets passed on to the program?)
claunia commented 2026-01-30 22:05:26 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from here.

Ah ha! Now we're getting somewhere. That version seems to work as expected, but now I need to figure out why.

At the very least, there's an application compatibility issue here since the older version I have does work in a normal cmd / powershell window.

@binarycrusader commented on GitHub (May 8, 2019): > I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from [here](https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1099). Ah ha! Now we're getting somewhere. That version seems to work as expected, but now I need to figure out why. At the very least, there's an application compatibility issue here since the older version I have does work in a normal cmd / powershell window.
claunia commented 2026-01-30 22:05:26 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from here.

Ok, I can reproduce with this exact version:

https://sourceforge.net/projects/cream/files/Vim/7.4.493/gvim-7-4-493.exe/download

I'm going to try newer versions from the cream for vim project and see if I can bisect the version space.

@binarycrusader commented on GitHub (May 8, 2019): > I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from [here](https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1099). Ok, I can reproduce with this exact version: https://sourceforge.net/projects/cream/files/Vim/7.4.493/gvim-7-4-493.exe/download I'm going to try newer versions from the cream for vim project and see if I can bisect the version space.
claunia commented 2026-01-30 22:05:26 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from here.

Ok, I can reproduce with this exact version:

https://sourceforge.net/projects/cream/files/Vim/7.4.493/gvim-7-4-493.exe/download

I'm going to try newer versions from the cream for vim project and see if I can bisect the version space.

Ok, I've narrowed it down to the last non-working version is <=:

https://sourceforge.net/projects/cream/files/Vim/7.4.711/gvim-7-4-711.exe/download

Versions >=:
https://sourceforge.net/projects/cream/files/Vim/7.4.827/gvim-7-4-827.exe/download

...appear to work as expected. Going to dig through the patches now and see if I can figure out what change altered the behavior and from there maybe we can figure out what Terminal is doing differently than cmd and powershell.

@binarycrusader commented on GitHub (May 8, 2019): > > I cannot reproduce this with Windows [Version 10.0.18362.86] and Vim.exe 8.1.1099 downloaded from [here](https://github.com/vim/vim-win32-installer/releases/tag/v8.1.1099). > > Ok, I can reproduce with this exact version: > > https://sourceforge.net/projects/cream/files/Vim/7.4.493/gvim-7-4-493.exe/download > > I'm going to try newer versions from the cream for vim project and see if I can bisect the version space. Ok, I've narrowed it down to the last non-working version is <=: https://sourceforge.net/projects/cream/files/Vim/7.4.711/gvim-7-4-711.exe/download Versions >=: https://sourceforge.net/projects/cream/files/Vim/7.4.827/gvim-7-4-827.exe/download ...appear to work as expected. Going to dig through the patches now and see if I can figure out what change altered the behavior and from there maybe we can figure out what Terminal is doing differently than cmd and powershell.
claunia commented 2026-01-30 22:05:26 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

I haven't been able to build vim yet to test, but I suspect this patch "fixed" the problem:

https://groups.google.com/forum/#!searchin/vim_dev/7.4.808%7Csort:date/vim_dev/SdP0hVtubNc/DQyq6otpHAAJ

"Read console input before calling MsgWaitForMultipleObjects()"

...which they changed to fix IME input on Windows 10.

@binarycrusader commented on GitHub (May 8, 2019): I haven't been able to build vim yet to test, but I suspect this patch "fixed" the problem: https://groups.google.com/forum/#!searchin/vim_dev/7.4.808%7Csort:date/vim_dev/SdP0hVtubNc/DQyq6otpHAAJ "Read console input before calling MsgWaitForMultipleObjects()" ...which they changed to fix IME input on Windows 10.
claunia commented 2026-01-30 22:05:27 +00:00
Author
Owner
Copy Link

@binarycrusader commented on GitHub (May 8, 2019):

I haven't been able to build vim yet to test, but I suspect this patch "fixed" the problem:

https://groups.google.com/forum/#!searchin/vim_dev/7.4.808%7Csort:date/vim_dev/SdP0hVtubNc/DQyq6otpHAAJ

"Read console input before calling MsgWaitForMultipleObjects()"

...which they changed to fix IME input on Windows 10.

Ok, I've confirmed that's the patch that fixed vim:

http://ftp.vim.org/pub/vim/patches/7.4/7.4.808

@zadjii-msft @DHowett-MSFT Is there a possible application compatibility concern here? It's fascinating to me that vim without that patch works as expected in the old cmd and powershell, but not in the new Windows Terminal. If this is a case of "it never should have worked", I guess we can move on, but at least we now know the cause and can look for the same problem if it happens again.

@binarycrusader commented on GitHub (May 8, 2019): > I haven't been able to build vim yet to test, but I suspect this patch "fixed" the problem: > > https://groups.google.com/forum/#!searchin/vim_dev/7.4.808%7Csort:date/vim_dev/SdP0hVtubNc/DQyq6otpHAAJ > > "Read console input before calling MsgWaitForMultipleObjects()" > > ...which they changed to fix IME input on Windows 10. Ok, I've confirmed that's the patch that fixed vim: http://ftp.vim.org/pub/vim/patches/7.4/7.4.808 @zadjii-msft @DHowett-MSFT Is there a possible application compatibility concern here? It's fascinating to me that vim without that patch works as expected in the old cmd and powershell, but not in the new Windows Terminal. If this is a case of "it never should have worked", I guess we can move on, but at least we now know the cause and can look for the same problem if it happens again.
claunia commented 2026-01-30 22:05:27 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 28, 2020):

Alright, this one came up during our v1 scrub - I think it's a /dup of #2397

@DHowett-MSFT commented on GitHub (Jan 28, 2020): Alright, this one came up during our v1 scrub - I think it's a /dup of #2397
claunia commented 2026-01-30 22:05:27 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jan 28, 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 (Jan 28, 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!
claunia commented 2026-01-30 22:05:27 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jan 28, 2020):

Actually, I take that back. I don't know what to do with this one.

I'd like to understand why the fix fixed this. 😄

@DHowett-MSFT commented on GitHub (Jan 28, 2020): Actually, I take that back. I don't know what to do with this one. I'd like to understand why the fix fixed this. :smile:
claunia commented 2026-01-30 22:05:27 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 2, 2021):

Okay I'm running through the big-ol backlog and came across this one. The root cause is fixed, but we don't totally understand why. The gist of the fix is:

static DWORD
wait_for_single_object(
    HANDLE hHandle,
    DWORD dwMilliseconds)
{
+   if (read_console_input(NULL, NULL, -2, NULL))
+       return WAIT_OBJECT_0;
    return WaitForSingleObject(hHandle, dwMilliseconds);
}

If you read first, then the key comes through??

69c76171f1/src/os_win32.c (L329)

but then there's these static variables that change whether that read_console_input(NULL, NULL, -2, NULL) immediately returns TRUE or FALSE.

I honestly don't know what exactly is going on here, or why this fixes it. Possible that reading 0 events from the buffer still toggles the console loch, flushing the characters through?

I'm not sure this is worth debugging carefully at the moment. The root cause seems addressed, and we haven't really had any reports of other bugs in this area in the last two years. I'm gonna close this out.

@zadjii-msft commented on GitHub (Dec 2, 2021): Okay I'm running through the big-ol backlog and came across this one. The root cause is _fixed_, but we don't totally understand why. The gist of the fix is: ```diff static DWORD wait_for_single_object( HANDLE hHandle, DWORD dwMilliseconds) { + if (read_console_input(NULL, NULL, -2, NULL)) + return WAIT_OBJECT_0; return WaitForSingleObject(hHandle, dwMilliseconds); } ``` If you read first, then the key comes through?? https://github.com/vim/vim/blob/69c76171f1a78b829196f72d7010fbe1d9ad2944/src/os_win32.c#L329 but then there's these static variables that change whether that `read_console_input(NULL, NULL, -2, NULL)` immediately returns `TRUE` or `FALSE`. I honestly don't know what exactly is going on here, or why this fixes it. Possible that reading 0 events from the buffer still toggles the console loch, flushing the characters through? I'm not sure this is worth debugging carefully at the moment. The root cause seems addressed, and we haven't really had any reports of other bugs in this area in the last two years. I'm gonna close this out.
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 Area-Input Issue-Bug Product-Terminal Resolution-External
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#819
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?