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

Windows vim broken on alt screen buffer #4978

New Issue
Closed
opened 2026-01-31 00:02:06 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 00:02:06 +00:00
Owner
Copy Link

Originally created by @lzybkr on GitHub (Nov 13, 2019).

Environment

Microsoft Windows NT 10.0.18363.0
Version: 0.6.3161.0

Steps to reproduce

Run vim from PowerShell with the following PowerShell function:

    function vim
    {
        Write-Host "$([char]0x1b)[?1049h"
        vim.exe @args
        Write-Host "$([char]0x1b)[?1049l"
    }

This is used to work around how vim screen scrapes the screen so it can restore it, but colors are messed up because screen scraping doesn't work with 24 bit colors.

Edit a file with at least double the number of lines in the window.

Go to the bottom, reposition the cursor, and move the cursor line wise up - rendering will be horribly broken.
Gztkkkk

Here's a guess at the commit introducing the regression: https://github.com/microsoft/terminal/pull/3160

Expected behavior

Rendering works the same as on the main screen buffer.

Actual behavior

Lines are duplicated or sometimes not, it's super confusing to understand what exactly is happening.

Originally created by @lzybkr on GitHub (Nov 13, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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. --> # Environment ```none Microsoft Windows NT 10.0.18363.0 Version: 0.6.3161.0 ``` # Steps to reproduce Run vim from PowerShell with the following PowerShell function: ```powershell function vim { Write-Host "$([char]0x1b)[?1049h" vim.exe @args Write-Host "$([char]0x1b)[?1049l" } ``` This is used to work around how vim screen scrapes the screen so it can restore it, but colors are messed up because screen scraping doesn't work with 24 bit colors. Edit a file with at least double the number of lines in the window. Go to the bottom, reposition the cursor, and move the cursor line wise up - rendering will be horribly broken. <kbd>G</kbd><kbd>z</kbd><kbd>t</kbd><kbd>k</kbd><kbd>k</kbd><kbd>k</kbd><kbd>k</kbd> <!-- A description of how to trigger this bug. --> Here's a guess at the commit introducing the regression: https://github.com/microsoft/terminal/pull/3160 # Expected behavior <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> Rendering works the same as on the main screen buffer. # Actual behavior <!-- What's actually happening? --> Lines are duplicated or sometimes not, it's super confusing to understand what exactly is happening.
claunia added the Help WantedProduct-ConhostIssue-BugArea-VTNeeds-Tag-Fix labels 2026-01-31 00:02:07 +00:00
claunia commented 2026-01-31 00:02:08 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Nov 14, 2019):

/cc @j4james
Any thoughts? Thanks!

@DHowett-MSFT commented on GitHub (Nov 14, 2019): /cc @j4james Any thoughts? Thanks!
claunia commented 2026-01-31 00:02:08 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 14, 2019):

I wasn't able to reproduce this in vim - not sure if I needed a specific version, or I was just doing something wrong - but I did manage to reproduce a similar issue when running some of my own alt buffer tests.

Note that this doesn't happen in conhost - only the Windows Terminal - so I'm assuming it's got something to do with the conpty layer. Also, I did a bisect, and the actual commit on which it first fails is ddcc06e911, so I don't think the DECSC/DECRC changes had anything to do with it.

I can try and do a bit more digging when I have some time, but the conpty stuff is outside my area of understanding, so I'm not sure I can tell you much more than this.

@j4james commented on GitHub (Nov 14, 2019): I wasn't able to reproduce this in vim - not sure if I needed a specific version, or I was just doing something wrong - but I did manage to reproduce a similar issue when running some of my own alt buffer tests. Note that this doesn't happen in conhost - only the Windows Terminal - so I'm assuming it's got something to do with the conpty layer. Also, I did a bisect, and the actual commit on which it first fails is ddcc06e911a18250c8544c7ea83011451e8256a2, so I don't think the DECSC/DECRC changes had anything to do with it. I can try and do a bit more digging when I have some time, but the conpty stuff is outside my area of understanding, so I'm not sure I can tell you much more than this.
claunia commented 2026-01-31 00:02:08 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Nov 15, 2019):

If it fails on ddcc06e (good find, thank you!) it's because we actually stopped using the in-package conhost (#3582, fixes #3553)!

@DHowett-MSFT commented on GitHub (Nov 15, 2019): If it fails on ddcc06e (good find, thank you!) it's because we actually stopped using the in-package conhost (#3582, fixes #3553)!
claunia commented 2026-01-31 00:02:08 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 15, 2019):

Yeah, that looks like the solution. Applying the changes from 0d106c8f99 fixed the problem for me. Hopefully that means it'll fix the OP's vim problem too.

@j4james commented on GitHub (Nov 15, 2019): Yeah, that looks like the solution. Applying the changes from 0d106c8f9998b9fdf98a699a2246322174c09ac1 fixed the problem for me. Hopefully that means it'll fix the OP's vim problem too.
claunia commented 2026-01-31 00:02:08 +00:00
Author
Owner
Copy Link

@lzybkr commented on GitHub (Nov 26, 2019):

It seems fixed now, thanks.

@lzybkr commented on GitHub (Nov 26, 2019): It seems fixed now, thanks.
claunia commented 2026-01-31 00:02:09 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Nov 26, 2019):

This may have actually been caused by #3553 -- we were accidentally using the windows console host instead of the one in the package. 3161 and 3181 both suffered from this 😄

@DHowett-MSFT commented on GitHub (Nov 26, 2019): This may have actually been caused by #3553 -- we were accidentally using the windows console host instead of the one in the package. 3161 and 3181 both suffered from this :smile:
claunia commented 2026-01-31 00:02:09 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Nov 26, 2019):

(Incidentally, this means it also works inbox on Windows 20H1, and not in 19H1, for non-Windows Terminal consumers.)

@DHowett-MSFT commented on GitHub (Nov 26, 2019): (Incidentally, this means it _also_ works inbox on Windows 20H1, and not in 19H1, for non-Windows Terminal consumers.)
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-VT Help Wanted Issue-Bug Needs-Tag-Fix Product-Conhost
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#4978
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?