Keep ESU collection inside synchronized output - #5495
Open
xz-dev wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When an application sends BSU, printable cells and ESU in one pane input batch, the printable cells may still be pending in the active
screen_write_ctxcollection when ESU is handled.screen_write_stop_sync()clearsMODE_SYNCand redraws lines already recorded insync_dirty. The still-pending collection is only flushed later byscreen_write_stop(), after synchronized mode has ended, so those cells can be written to the physical client outside the outgoingCSI ?2026h/CSI ?2026ltransaction. The final pane grid is correct, but a capable terminal may display the frame progressively instead of atomically.This is distinct from #4983, which covered structural TTY writes while BSU and ESU span multiple pane reads, and from #5419/#5420, which concerned cursor visibility during client redraw.
Fix
Handle application ESU with a
screen_write_ctx-aware helper:MODE_SYNCis still set, flush the active collection. In synchronized mode this records the affected lines insync_dirtyinstead of writing them to the client.screen_write_stop_sync()to clear the mode and redraw the complete dirty set inside physical synchronized output.The existing pane-only stop helper remains unchanged for resize, teardown and redraw callers that do not have an active parser collection.
Test evidence
The regression script is intentionally provided as a PR attachment rather than committed:
53adcc9f8024bfde719724557242d2ebda7109d91d28e4fac15af12c33316da9It starts an attached sync-capable nested tmux client, sends two complete 80x24 application synchronized-output frames, captures the physical client byte stream, and requires every frame-row marker to occur inside balanced outgoing DEC 2026 transactions.
Results against the same workload:
master(851c5a933d4838c32ad06c248b2ba975d106149c): fails withmarker 000000:00 outside synchronized output.Additional validation:
./configure --enable-utf8proc --enable-asanand builddecrqm-sync.shinput-requests.shscreen-redraw-cache.shscreen-redraw-outside.shtty-draw-line.sh