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

Sixel Termination Places Cursor in the Wrong Spot #22479

New Issue
Closed
opened 2026-01-31 08:14:35 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 08:14:35 +00:00
Owner
Copy Link

Originally created by @CannibalVox on GitHub (Nov 1, 2024).

Windows Terminal version

1.22.2912.0

Windows build number

10.0.19045.5011

Other Software

Ordinary windows CMD prompt, but I can reproduce with mingw and powershell as well.

Steps to reproduce

Display the following output from a file using type or cat

        #0;2;0;0;0#1;2;100;100;0
        #1~~@@vv@@~~@@!20~#0!20@#1!30~--\a a a

This displays some text, followed by a wide band of pixels with two pixel "new lines", followed by some text.

Display the following output from a file using type or cat

        #0;2;0;0;0#1;2;100;100;0
        #1~~@@vv@@~~@@!20~#0!20@#1!30~\a a a

This is the same display with no pixel new lines.

Note that in the first example, the text begins on the following line. In the second example, the text covers most of the image.

Expected Behavior

In the VT100.net explanation of sixels, it says the following:

When sixel display mode is enabled[...] When sixel mode is exited, the text cursor is set to the current sixel cursor position.
[...]
When sixel scrolling is disabled[...] When sixel mode is exited, the text cursor does not change from the position it was in when sixel mode was entered.

Actual Behavior

You can see from the examples above, that the windows terminal does not display either of these two behaviors. Instead, the text cursor seems to end up at where the sixel cursor was at the last time it experienced a carriage return. Personally, I would expect the text cursor in the second example to end up at the far right edge of the image instead of the far left edge.

Originally created by @CannibalVox on GitHub (Nov 1, 2024). ### Windows Terminal version 1.22.2912.0 ### Windows build number 10.0.19045.5011 ### Other Software Ordinary windows CMD prompt, but I can reproduce with mingw and powershell as well. ### Steps to reproduce Display the following output from a file using `type` or `cat` ```a a a a a P0;1;0q #0;2;0;0;0#1;2;100;100;0 #1~~@@vv@@~~@@!20~#0!20@#1!30~--\a a a ``` This displays some text, followed by a wide band of pixels with two pixel "new lines", followed by some text. Display the following output from a file using `type` or `cat` ```a a a a a P0;1;0q #0;2;0;0;0#1;2;100;100;0 #1~~@@vv@@~~@@!20~#0!20@#1!30~\a a a ``` This is the same display with no pixel new lines. Note that in the first example, the text begins on the following line. In the second example, the text covers most of the image. ### Expected Behavior In [the VT100.net explanation of sixels](https://vt100.net/docs/vt3xx-gp/chapter14.html), it says the following: > When sixel display mode is enabled[...] When sixel mode is exited, the text cursor is set to the current sixel cursor position. > [...] > When sixel scrolling is disabled[...] When sixel mode is exited, the text cursor does not change from the position it was in when sixel mode was entered. ### Actual Behavior You can see from the examples above, that the windows terminal does not display either of these two behaviors. Instead, the text cursor seems to end up at where the sixel cursor was at the last time it experienced a carriage return. Personally, I would expect the text cursor in the second example to end up at the far right edge of the image instead of the far left edge.
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 08:14:35 +00:00
claunia commented 2026-01-31 08:14:36 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Nov 1, 2024):

FYI private mode 8452 has no effect on this behavior

@CannibalVox commented on GitHub (Nov 1, 2024): FYI private mode 8452 has no effect on this behavior
claunia commented 2026-01-31 08:14:37 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Nov 1, 2024):

Based on information @j4james posted here: https://github.com/hackerb9/vt340test/blob/main/j4james/cursor_position.png

I think that this report is erroneous and that the behavior here is correct. I think maybe what I actually want is private mode 8452 implemented

@CannibalVox commented on GitHub (Nov 1, 2024): Based on information @j4james posted here: https://github.com/hackerb9/vt340test/blob/main/j4james/cursor_position.png I think that this report is erroneous and that the behavior here is correct. I think maybe what I actually want is private mode 8452 implemented
claunia commented 2026-01-31 08:14:37 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Nov 1, 2024):

Actually I take it back- because the extra newlines at the end shouldn't matter, should they? THey don't seem to matter in the above image and they don't matter on wezterm, for instance. So I think there's a bug but it's the opposite of what I thought:

The first sixel image should act the same way as the second sixel image.

@CannibalVox commented on GitHub (Nov 1, 2024): Actually I take it back- because the extra newlines at the end shouldn't matter, should they? THey don't seem to matter in the above image and they don't matter on wezterm, for instance. So I think there's a bug but it's the opposite of what I thought: The first sixel image should act the same way as the second sixel image.
claunia commented 2026-01-31 08:14:37 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 1, 2024):

Actually I take it back- because the extra newlines at the end shouldn't matter, should they?

They do matter. In much the same way that a newline takes up space in a text file, even if there is no text on that line, a graphic newline will take up space in a Sixel image, even if there are no pixels on that line.

It's complicated by the fact that the Sixel lines are a fraction of a text line, so the final text cursor position is often not aligned with the final Sixel position. This means you can sometimes add a graphic newline which appear to have no effect, because it's "rounding down" to the same text row as before.

@j4james commented on GitHub (Nov 1, 2024): > Actually I take it back- because the extra newlines at the end shouldn't matter, should they? They do matter. In much the same way that a newline takes up space in a text file, even if there is no text on that line, a graphic newline will take up space in a Sixel image, even if there are no pixels on that line. It's complicated by the fact that the Sixel lines are a fraction of a text line, so the final text cursor position is often not aligned with the final Sixel position. This means you can sometimes add a graphic newline which appear to have no effect, because it's "rounding down" to the same text row as before.
claunia commented 2026-01-31 08:14:37 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Nov 3, 2024):

Okay, got it

@CannibalVox commented on GitHub (Nov 3, 2024): Okay, got it
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-Triage
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#22479
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?