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

Bad formatting in Windows after exiting vim over ssh #22980

New Issue
Open
opened 2026-01-31 08:29:06 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:29:06 +00:00
Owner
Copy Link

Originally created by @DanielViberg on GitHub (Feb 27, 2025).

Originally assigned to: @DHowett on GitHub.

Windows Terminal version

1.21.10351.0

Windows build number

10.0.19045.0

Other Software

VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Feb 26 2025 16:35:59)
Included patches: 1-1151
OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2

Steps to reproduce

  1. From a linux machine, running gnome-terminal or foot
  2. ssh to windows 10 machine
  3. Start vim 9.1
  4. Exit vim 9.1 with :q!
  5. Observer vim graphical artifacts still in the bottom of the window

Image

  1. Resize the window and they go away

Script log:
out.log

Expected Behavior

No vim artifacts after exiting.

Actual Behavior

Vim artifacts left after exiting.

Originally created by @DanielViberg on GitHub (Feb 27, 2025). Originally assigned to: @DHowett on GitHub. ### Windows Terminal version 1.21.10351.0 ### Windows build number 10.0.19045.0 ### Other Software VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Feb 26 2025 16:35:59) Included patches: 1-1151 OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 ### Steps to reproduce 1. From a linux machine, running gnome-terminal or foot 2. ssh to windows 10 machine 3. Start vim 9.1 4. Exit vim 9.1 with :q! 5. Observer vim graphical artifacts still in the bottom of the window ![Image](https://github.com/user-attachments/assets/97da3fce-4723-42d7-be0c-05f267f3a69d) 7. Resize the window and they go away Script log: [out.log](https://github.com/user-attachments/files/19012369/out.log) ### Expected Behavior No vim artifacts after exiting. ### Actual Behavior Vim artifacts left after exiting.
claunia added the Issue-BugNeeds-Tag-FixNeeds-Attention labels 2026-01-31 08:29:06 +00:00
claunia commented 2026-01-31 08:29:09 +00:00
Author
Owner
Copy Link

@similar-issues-ai[bot] commented on GitHub (Feb 27, 2025):

We've found some similar issues:

  • #13184 , similarity score: 81%

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

@similar-issues-ai[bot] commented on GitHub (Feb 27, 2025): We've found some similar issues: - #13184 , similarity score: 81% If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue. > Note: You can give me feedback by 👍 or 👎 this comment.
claunia commented 2026-01-31 08:29:09 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 27, 2025):

Team notes: I directed Daniel here from the vim repo :)

@DHowett commented on GitHub (Feb 27, 2025): Team notes: I directed Daniel here from the vim repo :)
claunia commented 2026-01-31 08:29:10 +00:00
Author
Owner
Copy Link

@zewpo commented on GitHub (Mar 11, 2025):

Some notes from my investigation. This problem seems to only occur on windows 10, but not on windows 11. The terminal height must be greater than 46 lines for the problem to occur. Say, the height is 50 lines. the "mode" command shows 50 lines (and sometimes like 9001 lines!?). Then, after vim exits, the terminal application still appears as greater than 46 lines, but the "mode" command now reports only 46 lines. Also, in cases when the cursor was beyond line 46 when vim was started, then after exiting vim the cursor position snaps up to line ~46 when you start typing. I wonder if the virtual pty that is allocated in the sshd session on windows 10 is a bit different than the one in windows 11?

@zewpo commented on GitHub (Mar 11, 2025): Some notes from my investigation. This problem seems to only occur on windows 10, but not on windows 11. The terminal height must be greater than 46 lines for the problem to occur. Say, the height is 50 lines. the "mode" command shows 50 lines (and sometimes like 9001 lines!?). Then, after vim exits, the terminal application still appears as greater than 46 lines, but the "mode" command now reports only 46 lines. Also, in cases when the cursor was beyond line 46 when vim was started, then after exiting vim the cursor position snaps up to line ~46 when you start typing. I wonder if the virtual pty that is allocated in the sshd session on windows 10 is a bit different than the one in windows 11?
claunia commented 2026-01-31 08:29:10 +00:00
Author
Owner
Copy Link

@zewpo commented on GitHub (Mar 17, 2025):

Vim now has a patch to work around this "quirk" for now.

I'll try and provide the simplest C code that demonstrates the discrepency between Windows 10 and 11, that caused this issue.

@zewpo commented on GitHub (Mar 17, 2025): Vim now has a patch to work around this "quirk" for now. I'll try and provide the simplest C code that demonstrates the discrepency between Windows 10 and 11, that caused this issue.
claunia commented 2026-01-31 08:29:10 +00:00
Author
Owner
Copy Link

@zewpo commented on GitHub (Apr 7, 2025):

Vim now has a patch to work around this "quirk" for now.

I'll try and provide the simplest C code that demonstrates the discrepency between Windows 10 and 11, that caused this issue.

Apologies - I really struggled to narrow down a sub-set of which of the various console api interactions caused the problem between vim / windows 10 vs 11 / and inside an ssh session provided by windows ssh. I think I have provided enough steps to replicate it anyway? Let me know if there are any questions - I can try and help with this as best I can. The other point on this, is that it maybe not highly important anymore, since vim is now doing it in such a way to make it work properly on both windows 10 as well as windows 11. I just thought you might be interested to find out what the difference was, in vim's previous behavior, why it was different on windows 10 v 11 (inside the ssh session)

@zewpo commented on GitHub (Apr 7, 2025): > Vim now has a patch to work around this "quirk" for now. > > I'll try and provide the simplest C code that demonstrates the discrepency between Windows 10 and 11, that caused this issue. Apologies - I really struggled to narrow down a sub-set of which of the various console api interactions caused the problem between vim / windows 10 vs 11 / and inside an ssh session provided by windows ssh. I think I have provided enough steps to replicate it anyway? Let me know if there are any questions - I can try and help with this as best I can. The other point on this, is that it maybe not highly important anymore, since vim is now doing it in such a way to make it work properly on both windows 10 as well as windows 11. I just thought you might be interested to find out what the difference was, in vim's previous behavior, why it was different on windows 10 v 11 (inside the ssh session)
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 Issue-Bug Needs-Attention Needs-Tag-Fix
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#22980
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?