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

Implement CSI ? 2048 h (inband resize notification) #23856

New Issue
Open
opened 2026-01-31 08:54:24 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 08:54:24 +00:00
Owner
Copy Link

Originally created by @ldemailly on GitHub (Dec 4, 2025).

Description of the new feature

Given that there is no SIGWINCH on windows and using ReadConsoleInput is a pain when doing cross platform TUIs (because the codes are completely different than what you get from stdin)

It would be awesome for windows terminal to implement CSI ? 2048 h

cc @geofpwhite

Proposed technical implementation details

https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3704bd83

Originally created by @ldemailly on GitHub (Dec 4, 2025). ### Description of the new feature Given that there is no SIGWINCH on windows and using ReadConsoleInput is a pain when doing cross platform TUIs (because the codes are completely different than what you get from stdin) It would be awesome for windows terminal to implement CSI ? 2048 h cc @geofpwhite ### Proposed technical implementation details https://gist.github.com/rockorager/e695fb2924d36b2bcf1fff4a3704bd83
claunia added the Issue-FeatureProduct-ConhostPriority-3Area-VTProduct-Terminal labels 2026-01-31 08:54:25 +00:00
claunia commented 2026-01-31 08:54:25 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Dec 4, 2025):

IMO these are all half-measures. A handshake protocol between the terminal and the application(s) is needed.

@o-sdn-o commented on GitHub (Dec 4, 2025): IMO these are all half-measures. A handshake protocol between the terminal and the application(s) is needed.
claunia commented 2026-01-31 08:54:26 +00:00
Author
Owner
Copy Link

@ldemailly commented on GitHub (Dec 4, 2025):

IMO these are all half-measures. A handshake protocol between the terminal and the application(s) is needed.

can you elaborate ? there is already a handshake : send csi instructions, get replies

@ldemailly commented on GitHub (Dec 4, 2025): > IMO these are all half-measures. A handshake protocol between the terminal and the application(s) is needed. can you elaborate ? there is already a handshake : send csi instructions, get replies
claunia commented 2026-01-31 08:54:26 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Dec 4, 2025):

can you elaborate ? there is already a handshake : send csi instructions, get replies

I mean something like this:

Mandatory synchronization

When the terminal window is resized, the changes are only applied after a handshake between the terminal and the application. Successive multiple resizing of the window initiates the same number of handshakes.

Handshake steps:

  1. Terminal requests a new size, omitting all other parameters.
    • Application receives the request and prepares for resizing, e.g. by updating, cropping or deleting visible lines.
  2. Application replies with the same message as the request.
  3. Terminal applies the new size and sends the changes.
    • Application updates its UI.
Terminal:    ESC _ event=window ; size=<Width>,<Height> ESC \
Application: ESC _ event=window ; size=<Width>,<Height> ESC \
Terminal:    ESC _ event=window ; size=<Width>,<Height> ; cursor=<X>,<Y> ; region=<Left>,<Top>,<Right>,<Bottom> ; selection=<StartX>,<StartY>,<EndX>,<EndY>,<Mode> ESC \

Note that the terminal window resizing always reflows the scrollback, so the window size, cursor position, scrolling regions, and selection coordinates are subject to change during step 3. Upon receiving the resize request (step 1), a fullscreen application can prepare a scrollback by cropping visible lines to avoid unwanted line wrapping or line extrusion, then send a resize confirmation (step 2). In case the aplication's output is anchored to the current cursor position or uses scrolling regions, the application should wait after step 2 for the updated values before continuing to output.

Hypothetical case with Far Manager (FM):

  • FM saves visible original scrollback.
  • FM draws its UI on top of the visible original scrollback.
  • Terminal sends a resize request.
  • FM receives request.
  • FM restores the original scrollback.
  • FM replies on resize request.
  • Terminal receives reply.
  • Terminal resizes the window and reflows the scrollback.
  • Terminal sends modified window parameters.
  • FM receives modified window parameters.
  • FM saves the modified scrollback.
  • FM draws its UI on top of the scrollback.
@o-sdn-o commented on GitHub (Dec 4, 2025): > can you elaborate ? there is already a handshake : send csi instructions, get replies I mean something like [this](https://github.com/directvt/vtm/blob/master/doc/vt-input-mode.md#mandatory-synchronization): > #### Mandatory synchronization > > When the terminal window is resized, the changes are only applied after a handshake between the terminal and the application. Successive multiple resizing of the window initiates the same number of handshakes. > > Handshake steps: > 1. Terminal requests a new size, omitting all other parameters. > - Application receives the request and prepares for resizing, e.g. by updating, cropping or deleting visible lines. > 2. Application replies with the same message as the request. > 3. Terminal applies the new size and sends the changes. > - Application updates its UI. > > ``` > Terminal: ESC _ event=window ; size=<Width>,<Height> ESC \ > Application: ESC _ event=window ; size=<Width>,<Height> ESC \ > Terminal: ESC _ event=window ; size=<Width>,<Height> ; cursor=<X>,<Y> ; region=<Left>,<Top>,<Right>,<Bottom> ; selection=<StartX>,<StartY>,<EndX>,<EndY>,<Mode> ESC \ > ``` > > Note that the terminal window resizing always reflows the scrollback, so the window size, cursor position, scrolling regions, and selection coordinates are subject to change during step 3. Upon receiving the resize request (step 1), a fullscreen application can prepare a scrollback by cropping visible lines to avoid unwanted line wrapping or line extrusion, then send a resize confirmation (step 2). In case the aplication's output is anchored to the current cursor position or uses scrolling regions, the application should wait after step 2 for the updated values before continuing to output. > > Hypothetical case with Far Manager (FM): > - FM saves visible original scrollback. > - FM draws its UI on top of the visible original scrollback. > - Terminal sends a resize request. > - FM receives request. > - FM restores the original scrollback. > - FM replies on resize request. > - Terminal receives reply. > - Terminal resizes the window and reflows the scrollback. > - Terminal sends modified window parameters. > - FM receives modified window parameters. > - FM saves the modified scrollback. > - FM draws its UI on top of the scrollback.
claunia commented 2026-01-31 08:54:26 +00:00
Author
Owner
Copy Link

@ldemailly commented on GitHub (Dec 4, 2025):

What you have sounds great but it seems to be... not sure what actually.. a library? a terminal? a protocol proposal?

In any case, not sure what is wrong with the ?2048 semi standard existing proposal ?

@ldemailly commented on GitHub (Dec 4, 2025): What you have sounds great but it seems to be... not sure what actually.. a library? a terminal? a protocol proposal? In any case, not sure what is wrong with the `?2048` semi standard existing proposal ?
claunia commented 2026-01-31 08:54:26 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Dec 4, 2025):

This is an idea, just some thoughts on how it should ideally be.

what is wrong with the ?2048 semi standard existing proposal ?

This solves part of the problem (crossplatformability), but other questions remain.

@o-sdn-o commented on GitHub (Dec 4, 2025): This is an idea, just some thoughts on how it should ideally be. > what is wrong with the ?2048 semi standard existing proposal ? This solves part of the problem (crossplatformability), but other questions remain.
claunia commented 2026-01-31 08:54:27 +00:00
Author
Owner
Copy Link

@o-sdn-o commented on GitHub (Dec 4, 2025):

I'm not against it, I'm just sharing my thoughts

@o-sdn-o commented on GitHub (Dec 4, 2025): I'm not against it, I'm just sharing my thoughts
claunia commented 2026-01-31 08:54:27 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Dec 6, 2025):

Just as a point of comparison, DEC had similar functionality on their VAX VT220 emulator. VTEEWR (Enable Window Event Reports) was an OSC sequence which let you request notifications for a number of different events: window resizing, moving, minimizing and restoring, losing and gaining focus. The notifications for those events were also in the form of an OSC sequence.

For example \e]2E;5\e\\ would enable window resizing reports (that's event 5), and an example report would look something like \e]2R;5;1.2;3.4;80;24\e\\. The 5 indicates the event type, 1.2 and 3.4 are the x and y coordinates of the window, and 80 and 24 indicate the width and height (resize events included both the position and size).

@j4james commented on GitHub (Dec 6, 2025): Just as a point of comparison, DEC had similar functionality on their VAX VT220 emulator. `VTEEWR` (Enable Window Event Reports) was an `OSC` sequence which let you request notifications for a number of different events: window resizing, moving, minimizing and restoring, losing and gaining focus. The notifications for those events were also in the form of an `OSC` sequence. For example `\e]2E;5\e\\` would enable window resizing reports (that's event 5), and an example report would look something like `\e]2R;5;1.2;3.4;80;24\e\\`. The 5 indicates the event type, 1.2 and 3.4 are the x and y coordinates of the window, and 80 and 24 indicate the width and height (resize events included both the position and size).
claunia commented 2026-01-31 08:54:27 +00:00
Author
Owner
Copy Link

@ldemailly commented on GitHub (Dec 6, 2025):

nice that would work too. @rockorager how come you (someone else?) came up with a different thing then?

@ldemailly commented on GitHub (Dec 6, 2025): nice that would work too. @rockorager how come you (someone else?) came up with a different thing then?
claunia commented 2026-01-31 08:54:28 +00:00
Author
Owner
Copy Link

@rockorager commented on GitHub (Dec 6, 2025):

  1. I wasn't aware of it
  2. Having pixels is very nice, would have needed an extension to add that
  3. Private modes are nice because there is an established query mechanism for them

Cool that there was an existing mode for this though!

@rockorager commented on GitHub (Dec 6, 2025): 1. I wasn't aware of it 2. Having pixels is very nice, would have needed an extension to add that 3. Private modes are nice because there is an established query mechanism for them Cool that there was an existing mode for this though!
claunia commented 2026-01-31 08:54:28 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 10, 2025):

You know, I don't hate it. We already have in-band signaling for Windows consumers, so why not? There's some interesting artifacts that will be introduced by our hosting infrastructure, though.

@DHowett commented on GitHub (Dec 10, 2025): You know, I don't hate it. We already have in-band signaling for _Windows_ consumers, so why not? There's some interesting artifacts that will be introduced by our hosting infrastructure, though.
claunia commented 2026-01-31 08:54:28 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 10, 2025):

I'm putting it on the backlog at a not super high priority. :)

@DHowett commented on GitHub (Dec 10, 2025): I'm putting it on the backlog at a not super high priority. :)
claunia commented 2026-01-31 08:54:28 +00:00
Author
Owner
Copy Link

@gdamore commented on GitHub (Dec 19, 2025):

The CSI 2048 mechanism has got some broad acceptance and includes pixel support (needed for sixel graphics, kitty graphics, etc.), and it would be nicer for a number of applications than win32-input-mode extensions (because win32-input-mode is kind of all or nothing proposition - if your application does not properly clean up you can't type anything to fix the terminal, all you can do is close it.)

That said, for my use case, win32-input-mode extensions for this would work perfectly well.

@gdamore commented on GitHub (Dec 19, 2025): The CSI 2048 mechanism has got some broad acceptance and includes pixel support (needed for sixel graphics, kitty graphics, etc.), and it would be nicer for a number of applications than win32-input-mode extensions (because win32-input-mode is kind of all or nothing proposition - if your application does not properly clean up you can't type anything to fix the terminal, all you can do is close it.) That said, for my use case, win32-input-mode extensions for this would work perfectly well.
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 Issue-Feature Priority-3 Product-Conhost Product-Terminal
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#23856
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?