Terminal: Implement synchronized update control sequences

[Delta456]

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

[zadjii-msft]

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 \

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]

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 @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]

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

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:

• We implement support for the DCS version of this sequence.
• _At the same time_, as we add support for the DCS version, we add support for the DECSET/DECRST version.
• At the same time, iTerm2 adds support for the DECSET/DECRST version.

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 @gnachman, but this seems like a reasonable path, and one that would work cross-platform. Thoughts?

notes: terminal-wg pr

[gnachman]

I am fine with this. I believe Kitty has also implemented support for this control sequence, so check with @kovidgoyal too.

[kovidgoyal]

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.