Rendering misbehaviour and test failures under vttest

[EnronEvolved]

I thought I'd try vttest out on ghostty, and I noticed a few areas of aberrant behaviour which are not present on other terminal emulators. Here are a few of them.

1. The screen does not always update when expected: something needs to force a screen update, like adjusting the size of the terminal. This manifests in many places, including exiting the program, and test type 2 ("Test of screen features"). It's easy to mistake for a crash, and (at least on exit) doesn't seem to happen consistently.
2. Text colours are not handled properly under test type 2. While the background changes colour (which is more than can be said for Alacritty), the text colour doesn't, so you end up with a completely white screen instead of black-on-white text. Xterm and Gnome Terminal pass this test.
3. No support for blinking text, unlike Xterm which produces blinking text under test type 2.
4. The terminal completely fails to render anything in test type 7 (VT52 mode) correctly. Xterm passes with flying colours.

How should these be dealt with? Should any more vttest problems be reported?

[aragilar]

zutty appears to have a good test suite and records what tests it passes/fails as part of its release (see https://tomscii.sig7.se/zutty/doc/VTTEST.html and https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-of-Zutty)

[pluiedev]

Blinking text is a known missing feature (see #5217), and I'm not sure if we necessarily have VT52 support. It should be noted that while Ghostty is a terminal emulator, it's not necessarily 100% a VT100 emulator — like most modern terminal emulators it's more an xterm-like emulator. That being said, if we're not doing something xterm does then we should try to do that as well.

[aragilar]

I'm somewhat confused by this statement, xterm very much emulates a VT100 (it emulates more than VT100, in that xterm's features set is a superset of a VT100) and so by induction if Ghostty is supposed to do the same thing as xterm, then VT100 support shouldn't be in question. I've personally switched back to xterm (not from Ghostty, but others, and was looking at possibly switching but given there isn't any conformance testing via vttest, I'd be hesitant to do so if I'm going to run into the same issues I saw with other emulators) because of incorrect behaviour by other emulators.

I'd suggest copying what zutty does for its testing (as then it's clear to everyone what's missing, and where fixes can be made).

[pluiedev]

What I mean here is that we don't base our behavior completely on what VT100 does — for instance, we don't allow the KAM mode by default (although it is a toggleable option¹) since that's scantly used by modern terminal interfaces and apps. In general the backwards compatibility to xterm (and VT100 by extension) is not necessarily guaranteed by modern terminals (e.g. Kitty, WezTerm, VTE-based terminals like GNOME Console/Terminal, Alacritty, etc.) because frankly large parts of the feature set are archaic and don't make sense in the present-day context (such as KAM mode).

Is there a convincing case other than theoretical conformance, that we should:

• Go out of the way to emulate actual physical machines that rarely anyone has access to anymore (so much so that they're actual collector's items);
• Implement features that sparsely anyone uses anymore (aside from the ones I've mentioned that are on our roadmap such as blinking text);
• Comply to a test suite that's literally older than I am by a few decades (and Mitchell too, if I recall correctly)?

Please enlighten me.

Footnotes

1. A theoretically toggleable option, for that matter. Searching for vt-kam-allowed = true across the entirety of GitHub produces zero hits. ↩

[aragilar]

Again, I suggest looking at what zutty does, it's clear what is supported and what is not (and what is to be developed and what will never be supported). Then if people need obscure features, they can make a choice as to whether said terminal meets their needs.

Frankly, approaching this as not as "hey, here's a way for users and devs to be clear what will be supported and here's a test to check this" and rather "nah, stuff that started development in the 80s is bad and we don't care" (noting that vttest last had a release in December 2024, which from the changelog included sixel improvements, which does seem like a thing worth having more tests of) tells me that Ghostty will never be for me.

[pluiedev]

We do not and will not support Sixels either way (#2496). You're free to decide whether Ghostty is for you, although we do reserve the right to pick and choose what we do and don't implement — an approach that I might add is true for the vast majority of modern terminal emulators.

Some things will come and go, and what looked like to be good ideas before may become obstacles in the future (e.g. termcap/terminfo). We can't stay in the past forever.

[rhodes-b]

Again, I suggest looking at what zutty does, it's clear what is supported and what is not

While its not perfect yet (as in missing information) ghostty has information on what it supports on the docs site, maybe you missed that part
https://ghostty.org/docs/vt

[mitchellh]

Generally speaking, the answer to this is "it depends."

There is a lot that vttest tests that is completely irrelevant for modern terminals. I originally set out to pass vttest completely and fell back to this more nuanced approach, balancing with our desire to match xterm as closely as possible.

I think more specifically, my answer would be: if we can get a vttest passing without impacting other users, performance, or security, then I'd likely merge the PR. (Note on the security point, the best option there is to usually make these opt-in).

Another specific answer is if there is real software out there that is used at some reasonable scale and it's not working in Ghostty, then of course we'll prioritize that.

The terminal completely fails to render anything in test type 7 (VT52 mode) correctly. Xterm passes with flying colours.

This is an easy one: we don't plan on supporting VT52 mode. I'm not sure what the lowest VT compatibility is I'd settle on but it's definitely higher than that.