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

[PR #9307] [MERGED] Introduce a mechanism for passing through DCS data strings #27530

New Issue
Open
opened 2026-01-31 09:22:32 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 09:22:32 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/microsoft/terminal/pull/9307
Author: @j4james
Created: 2/28/2021
Status: ✅ Merged
Merged: 4/30/2021
Merged by: @undefined

Base: main ← Head: dcs-passthrough

📝 Commits (5)

  • 6c0b8e5 Introduce a mechanism for handling DCS data strings.
  • 08c7ed7 Simplify string termination to match DEC terminal behavior.
  • a94fbbe Update tests to account for changes in DCS behavior.
  • 2cbc54d Add test verifying data strings with various terminators.
  • a4a0fa1 Fix incorrect case value in output engine test.

📊 Changes

9 files changed (+249 additions, -186 deletions)

View changed files

📝 src/terminal/parser/IStateMachineEngine.hpp (+3 -0)
📝 src/terminal/parser/InputStateMachineEngine.cpp (+15 -0)
📝 src/terminal/parser/InputStateMachineEngine.hpp (+2 -0)
📝 src/terminal/parser/OutputStateMachineEngine.cpp (+18 -0)
📝 src/terminal/parser/OutputStateMachineEngine.hpp (+2 -0)
📝 src/terminal/parser/stateMachine.cpp (+83 -145)
📝 src/terminal/parser/stateMachine.hpp (+6 -8)
📝 src/terminal/parser/ut_parser/OutputEngineTest.cpp (+21 -30)
📝 src/terminal/parser/ut_parser/StateMachineTest.cpp (+99 -3)

📄 Description

This PR introduces a mechanism via which DCS data strings can be passed
through directly to the dispatch method that will be handling them, so
the data can be processed as it is received, rather than being buffered
in the state machine. This also simplifies the way string termination is
handled, so it now more closely matches the behaviour of the original
DEC terminals.

  • Initial support for DCS sequences was introduced in PR #6328.
  • Handling of DCS (and other) C1 controls was added in PR #7340.
  • This is a prerequisite for Sixel (#448) and Soft Font (#9164) support.

The way this now works, a DCS sequence is dispatched as soon as the
final character of the VTID is received. Based on that ID, the
OutputStateMachineEngine should forward the call to the corresponding
dispatch method, and its the responsibility of that method to return an
appropriate handler function for the sequence.

From then on, the StateMachine will pass on all of the remaining bytes
in the data string to the handler function. When a data string is
terminated (with CAN, SUB, or ESC), the StateMachine will pass
on one final ESC character to let the handler know that the sequence
is finished. The handler can also end a sequence prematurely by
returning false, and then all remaining data bytes will be ignored.

Note that once a DCS sequence has been dispatched, it's not possible
to abort the data string. Both CAN and SUB are considered valid
forms of termination, and an ESC doesn't necessarily have to be
followed by a \ for the string terminator. This is because the data
string is typically processed as it's received. For example, when
outputting a Sixel image, you wouldn't erase the parts that had already
been displayed if the data string is terminated early.

With this new way of handling the string termination, I was also able to
simplify some of the StateMachine processing, and get rid of a few
states that are no longer necessary. These changes don't apply to the
OSC sequences, though, since we're more likely to want to match the
XTerm behavior for those cases (which requires a valid ST control for
the sequence to be accepted).

Validation Steps Performed

For the unit tests, I've had to make a few changes to some of the
OutputEngineTests to account for the updated StateMachine
processing. I've also added a new StateMachineTest to confirm that the
data strings are correctly passed through to the string handler under
all forms of termination.

To test whether the framework is actually usable, I've been working on
DRCS Soft Font support branched off of this PR, and haven't encountered
any problems. To test the throughput speed, I also hacked together a
basic Sixel parser, and that seemed to perform reasonably well.

Closes #7316

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/microsoft/terminal/pull/9307 **Author:** [@j4james](https://github.com/j4james) **Created:** 2/28/2021 **Status:** ✅ Merged **Merged:** 4/30/2021 **Merged by:** [@undefined](undefined) **Base:** `main` ← **Head:** `dcs-passthrough` --- ### 📝 Commits (5) - [`6c0b8e5`](https://github.com/microsoft/terminal/commit/6c0b8e5c09703f2c4f610e66b6109fa26494422e) Introduce a mechanism for handling DCS data strings. - [`08c7ed7`](https://github.com/microsoft/terminal/commit/08c7ed78dcbb2d76461c073620361870acba9ea6) Simplify string termination to match DEC terminal behavior. - [`a94fbbe`](https://github.com/microsoft/terminal/commit/a94fbbe1663b8063a16154accb99524cf2550b37) Update tests to account for changes in DCS behavior. - [`2cbc54d`](https://github.com/microsoft/terminal/commit/2cbc54d6b3a4e3dfea10d7f91312fee3aec47bc3) Add test verifying data strings with various terminators. - [`a4a0fa1`](https://github.com/microsoft/terminal/commit/a4a0fa14ee304d7604035c1cc5ff17de3c8b28d9) Fix incorrect case value in output engine test. ### 📊 Changes **9 files changed** (+249 additions, -186 deletions) <details> <summary>View changed files</summary> 📝 `src/terminal/parser/IStateMachineEngine.hpp` (+3 -0) 📝 `src/terminal/parser/InputStateMachineEngine.cpp` (+15 -0) 📝 `src/terminal/parser/InputStateMachineEngine.hpp` (+2 -0) 📝 `src/terminal/parser/OutputStateMachineEngine.cpp` (+18 -0) 📝 `src/terminal/parser/OutputStateMachineEngine.hpp` (+2 -0) 📝 `src/terminal/parser/stateMachine.cpp` (+83 -145) 📝 `src/terminal/parser/stateMachine.hpp` (+6 -8) 📝 `src/terminal/parser/ut_parser/OutputEngineTest.cpp` (+21 -30) 📝 `src/terminal/parser/ut_parser/StateMachineTest.cpp` (+99 -3) </details> ### 📄 Description This PR introduces a mechanism via which DCS data strings can be passed through directly to the dispatch method that will be handling them, so the data can be processed as it is received, rather than being buffered in the state machine. This also simplifies the way string termination is handled, so it now more closely matches the behaviour of the original DEC terminals. * Initial support for DCS sequences was introduced in PR #6328. * Handling of DCS (and other) C1 controls was added in PR #7340. * This is a prerequisite for Sixel (#448) and Soft Font (#9164) support. The way this now works, a `DCS` sequence is dispatched as soon as the final character of the `VTID` is received. Based on that ID, the `OutputStateMachineEngine` should forward the call to the corresponding dispatch method, and its the responsibility of that method to return an appropriate handler function for the sequence. From then on, the `StateMachine` will pass on all of the remaining bytes in the data string to the handler function. When a data string is terminated (with `CAN`, `SUB`, or `ESC`), the `StateMachine` will pass on one final `ESC` character to let the handler know that the sequence is finished. The handler can also end a sequence prematurely by returning false, and then all remaining data bytes will be ignored. Note that once a `DCS` sequence has been dispatched, it's not possible to abort the data string. Both `CAN` and `SUB` are considered valid forms of termination, and an `ESC` doesn't necessarily have to be followed by a `\` for the string terminator. This is because the data string is typically processed as it's received. For example, when outputting a Sixel image, you wouldn't erase the parts that had already been displayed if the data string is terminated early. With this new way of handling the string termination, I was also able to simplify some of the `StateMachine` processing, and get rid of a few states that are no longer necessary. These changes don't apply to the `OSC` sequences, though, since we're more likely to want to match the XTerm behavior for those cases (which requires a valid `ST` control for the sequence to be accepted). ## Validation Steps Performed For the unit tests, I've had to make a few changes to some of the `OutputEngineTests` to account for the updated `StateMachine` processing. I've also added a new `StateMachineTest` to confirm that the data strings are correctly passed through to the string handler under all forms of termination. To test whether the framework is actually usable, I've been working on DRCS Soft Font support branched off of this PR, and haven't encountered any problems. To test the throughput speed, I also hacked together a basic Sixel parser, and that seemed to perform reasonably well. Closes #7316 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-31 09:22:32 +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 pull-request
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#27530
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?