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

End of line cursor position differences when app is run in Windows Terminal #11472

New Issue
Open
opened 2026-01-31 02:48:35 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 02:48:35 +00:00
Owner
Copy Link

Originally created by @tlmii on GitHub (Nov 17, 2020).

This isn't so much a bug report as I'm hoping for clarification on some behavior we're seeing in Windows Terminal related to a bug over at HttpRepl. Rich Turner suggested I file here to get more details.

I'm trying to understand the different behavior I'm seeing around the cursor position when our app (a dotnet global tool, though it doesn't appear specific to that type of app) is run from a normal cmd.exe prompt vs when it is run from within Windows Terminal, in a profile that launches cmd.exe. Specifically, this is about how the cursor position is updated when it is at the end of a line.

When our app does a Console.Write(char), in most cases we see the Console.CursorLeft (checked before and after the Write call) increase to the next slot after the character that was just written. Where we see the difference is when we Console.WriteLine(char) to the last slot on a line.

Running our app in vanilla cmd.exe, the character is written and the cursor visibly moves down to the beginning of the next line. Checking Console.CursorLeft and Console.CursorTop, we can see that the former reset to 0 and the latter increased by 1.

Running our app in cmd.exe launched in a Windows Terminal profile, the character is written, but the cursor disappears. Checking Console.CursorLeft and Console.CursorTop, we can see that neither of them changed - they now refer to the slot to which the character was just written.

Steps to reproduce

I set up a fairly minimal repro that demonstrates the difference. Run the app, start typing characters, and watch the upper-left of the console where we are printing the current Console.CursorLeft/Console.CursorTop position. Try it in both vanilla cmd.exe and cmd.exe from within Windows Terminal. Note the different behavior when you get to the last character on the line (and subsequent characters, actually, but I assume that's a derivative problem).

Note that the behavior is also different (in the same way) between a vanilla powershell prompt and a powershell prompt from within Windows Terminal.

Environment

It doesn't seem tied to a particular version of Windows or Terminal, but I've confirmed it on:

Windows build number: 10.0.20257.0
Windows Terminal version (if applicable): 1.5.3142.0

Expected behavior

I'm not asserting that this is unexpected behavior, necessarily. Instead I'm looking for clarity - maybe a little bit of "why" but also if it is possible for us to detect the different behavior so we can account for it.

Actual behavior

The behavior of the cursor position within a console app differs when it is run in Windows Terminal vs not.

Originally created by @tlmii on GitHub (Nov 17, 2020). This isn't so much a bug report as I'm hoping for clarification on some behavior we're seeing in Windows Terminal related to a [bug over at HttpRepl](https://github.com/dotnet/HttpRepl/issues/443). Rich Turner [suggested](https://twitter.com/richturn_ms/status/1328803640929259521) I file here to get more details. I'm trying to understand the different behavior I'm seeing around the cursor position when our app (a dotnet global tool, though it doesn't appear specific to that type of app) is run from a normal cmd.exe prompt vs when it is run from within Windows Terminal, in a profile that launches cmd.exe. Specifically, this is about how the cursor position is updated when it is at the end of a line. When our app does a `Console.Write(char)`, in most cases we see the `Console.CursorLeft` (checked before and after the Write call) increase to the next slot after the character that was just written. Where we see the difference is when we `Console.WriteLine(char)` to the last slot on a line. Running our app in vanilla cmd.exe, the character is written and the cursor visibly moves down to the beginning of the next line. Checking `Console.CursorLeft` and `Console.CursorTop`, we can see that the former reset to 0 and the latter increased by 1. Running our app in cmd.exe launched in a Windows Terminal profile, the character is written, but the cursor disappears. Checking `Console.CursorLeft` and `Console.CursorTop`, we can see that neither of them changed - they now refer to the slot to which the character was just written. # Steps to reproduce I set up a fairly minimal [repro](https://github.com/tlmii/ConsoleEndLineProof/blob/main/Program.cs) that demonstrates the difference. Run the app, start typing characters, and watch the upper-left of the console where we are printing the current `Console.CursorLeft`/`Console.CursorTop` position. Try it in both vanilla cmd.exe and cmd.exe from within Windows Terminal. Note the different behavior when you get to the last character on the line (and subsequent characters, actually, but I assume that's a derivative problem). Note that the behavior is also different (in the same way) between a vanilla powershell prompt and a powershell prompt from within Windows Terminal. # Environment It doesn't seem tied to a particular version of Windows or Terminal, but I've confirmed it on: ```none Windows build number: 10.0.20257.0 Windows Terminal version (if applicable): 1.5.3142.0 ``` # Expected behavior I'm not asserting that this is unexpected behavior, necessarily. Instead I'm looking for clarity - maybe a little bit of "why" but also if it is possible for us to detect the different behavior so we can account for it. # Actual behavior The behavior of the cursor position within a console app differs when it is run in Windows Terminal vs not.
claunia added the Issue-QuestionNeeds-Tag-FixResolution-Answered labels 2026-01-31 02:48:36 +00:00
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-Question Needs-Tag-Fix Resolution-Answered
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#11472
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?