Repository navigation
Implement synchronized update control sequences #8331
Description
Description of the new feature/enhancement
https://gitlab.com/gnachman/iterm2/-/wikis/synchronized-updates-spec
The goal of synchronized updates is to avoid showing a half-drawn screen, such as while paging through a document in an editor.
A new control sequence is proposed that indicates the beginning and end of a update. No new content should be rendered by the terminal emulator until the update ends, at which point any changes made during the update should be applied atomically.
The purpose of this sequence is to provide a hint to the terminal emulator about how to draw atomically. If it turns out to be too difficult to do under some particular input, the hint can be safely ignored
### Tasks
Reacted by Lukas Neubert, Raul Hernandez, OpenSourceAnarchist, Delyan Angelov, larpon, JalonSolov, ylluminate, WSLUser, Jake, Steve Lee and 11 more
Activity
zadjii-msft commentedon Nov 19, 2020
Yea okay, this seems well thought out. I like that there are contingincies included for "what happens when the client app disconnects before sending an <end>". Plus, I think we did add support for DCS sequences relatively recently, so this shouldn't be too bad.
Part of the trick here is gonna be conpty, and the way we use that to render the effects of output on the console buffer. I'd guess that this would have to be implemented in
conhost, and then at the end of the synchronized update, conhost would render once to the terminal. That makes sense to me.j4james commentedon Nov 19, 2020
Note that this idea was discussed in terminal-wg a while back, and I think it was generally agreed that a DCS sequence was a bad choice for this. One of the benefits of this functionality is that it shouldn't require feature detection - if a terminal doesn't support it, then you just don't get the optimisation. However, that's not the case if you're using a DCS sequence, because there are a number of terminals that will output garbage if you send them an unrecognised DCS. So now an app can't really use this functionality unless they first determine whether it's supported somehow.
As is typical for terminal-wg, there was no official conclusion to the discussion, but the general consensus seemed to have been that a DECSET private mode sequence would be preferable, and the mode number that was settled on was 2026. I know at least one terminal has implemented synchronized updates via mode 2026, and at least one application is using that mode.
Also I know George Nachman (@gnachman) has said "If I had it to do over again, I'd push for DECSET/DECRST", but he hasn't actually agreed to supporting the proposed mode in iTerm2 as far as I'm aware. If we're going to implement this, I'd much rather we used a DECSET mode than DCS, but I'd also like to have seen some definite commitment to that approach from people like iTerm2.
zadjii-msft commentedon Nov 19, 2020
Guh, I hate that. Maybe we come up with an agreement between us and iTerm2 to move forward onto a DECSET/DECRST implementation. We'd obviously have to still support the DCS version of the sequence, but maybe we can help push the ecosystem forward a bit here. Here's what I'm thinking:
At this point, we'd update any existing documentation to suggest that app developers use the new version of the sequence, and the old one is deprecated. Terminal emulators that haven't been updated with support for the new sequence will silently ignore it. Apps that aren't updated to use the new sequence will still continue to work (and will start working on the console/Terminal).
This would obviously require buyoff from George Nachman (@gnachman), but this seems like a reasonable path, and one that would work cross-platform. Thoughts?
notes: terminal-wg pr
gnachman commentedon Nov 19, 2020
I am fine with this. I believe Kitty has also implemented support for this control sequence, so check with Kovid Goyal (@kovidgoyal) too.
kovidgoyal commentedon Nov 20, 2020
You can go ahead and use DECSET/DECRESET if it floats your boat. Since you are also implementing support for the DCS version, I dont really care. I will note that the only terminals that dont support DCS sequences are Apple's and the Linux kernel console. Using DECSET/DECRESET means that no future modifications can be made to the protocol to implement additional features. Which will mean in the long term that DECSET/DECRESET will be the deprecated ones, but hey, no harm in having them, just another redundant code path. Just be careful when choosing numbers for the codes to not conflict with existing uses, which was one of the motivations for choosing DCS in the first place.
[-]implement synchronized updates[/-][+]Implement synchronized update control sequence[/+]13 remaining items
Delta456 commentedon Jun 26, 2023
Any updates or progress on this?
Delta456 commentedon Apr 23, 2025
Dustin L. Howett (@DHowett) Leonard Hecker (@lhecker) Thank you so much for implementing this long due feature 🙏
ldemailly commentedon Aug 10, 2025
So I am still seeing heavy flickering unique to windows terminal... yet this is closed as fixed... should I open a new issue then
Anyone else seeing it not working ?
DHowett commentedon Aug 10, 2025
It hasn't been released yet, unless you're using the Canary channel!
ldemailly commentedon Aug 10, 2025
Ah that gives me hope - so even the "Terminal Preview" from store app doesn't have that:
Windows Terminal Preview
Version: 1.23.12102.0