Kakoune: [builtin-terminal-ui] macOS Terminal.app fails to ignore "synchronised update" escapes

[arachsys]

I've been running with the builtin-terminal-ui branch for a little while, but happened to run it on a macOS "Mojave" machine from the bundled Apple Terminal.app (version 2.9.5) for the first time this weekend and saw dramatic screen corruption.

This is easy to explain because the leaking escape code is visible: it's caused by iTerm2 "synchronised update" sequences. Instead of ignoring '\033P=2s' (for example), Terminal.app ignores '\033P' and then echos '=2s'. Quick demo:

$ printf '\033P=1s\033\\\033P=2s\033\\'
=1s=2s$

in Terminal.app, but

$ printf '\033P=1s\033\\\033P=2s\033\\'
$

anywhere else I can think of to try.

Note that Mojave is not the latest release of macOS, and I'm afraid I don't have access to a machine running the most recent version, so can't confirm if this behaviour is already fixed on Apple's side. (They're usually bad at fixing stuff like this, though.)

The benefit of atomic redraws via ESC P=1s sequences is clear, so I suspect this is something that can't easily be tackled without regressing better behaved terminals or doing something truly ugly like checking for cursor movement after emitting a test sequence.

But I thought I'd pass along the observation nonetheless. Perhaps the right fix is just a FAQ entry on buggy terminals when builtin-terminal-ui is merged to master?

[arachsys]

Looks like PuTTY suffered similar indigestion, reported in https://github.com/mawww/kakoune/issues/3705

[lenormf]

Similarly to #3705, if this isn't a bug in Kakoune, the issue should be reported to the relevant project.

[arachsys]

I don't disagree, and I will indeed report the incorrectly-handled DCS sequences to the /dev/null simulation that is Apple's Radar system, more for my own peace of mind than because I expect them to bother to read it.

But I know from personal experience that it's handy to be warned about common non-compliances in popular systems I don't use myself, when they affect my software, if only so that I can document them to avoid repeated vague symptomatic bug reports.

[mawww]

I am tempted to remove synchronised update messages, they should not be necessary as we dump all the update in a big go, and they indeed lead to issues with various terminals (linux console included).

[arachsys]

Ah, interesting. I hadn't spotted that this breaks on Linux vtys too. Networking must have been unusually reliable here recently!

That's a more convincing example than either PuTTY or Terminal.app. TERM=linux is specified solely by console_codes(4), where DCS sequences (and their length/termination requirements) aren't mentioned and which doesn't claim xterm compatibility, so it's hard to argue this is a kernel bug.

I'm sure the fundamental idea of skipping ncurses and cleanly using ESC sequences direct is still a very good one: realistically some large subset of xterm capabilities works for every real-world terminal now. It's just that one has to be a bit careful not to expand that subset too broadly to avoid breakage in places you don't frequently test.

[vbauerster]

Note that Mojave is not the latest release of macOS, and I'm afraid I don't have access to a machine running the most recent version, so can't confirm if this behaviour is already fixed on Apple's side. (They're usually bad at fixing stuff like this, though.)

Can confirm that's been fixed in latest Terminal.app v2.11

UPD: I did check inside tmux. So pure Terminal.app still echoes extra =1s=2s. Takeaway: use tmux :)