> We have an automated regression testing setup to run VTTEST in Zutty and verify that the output is a pixel-perfect match of the pre-approved video output. You can thus expect the terminal output to be correct – be it driven by tmux, emacs (with org-mode, helm, magit, etc.) or whatever else.
Which sounds like it might be useful for you? https://github.com/tomszilagyi/zutty
Just before the section you quoted, it says:
> Zutty passes the subset of VTTEST screens that we care about
FWIW, wezterm passes the subset of vttest screens that I care about too :-p
More seriously though, I can't use anything from zutty as it has an incompatible license, and that approach still doesn't resolve the main issue that I have with vttest, which is that it requires a human to interpret the display and reverse engineer what's happening from the code.
esctest is a much more reasonable target for conformance testing: https://gitlab.freedesktop.org/terminal-wg/esctest/-/merge_r...
For example, you should maybe open a discussion on what you're seeing in vttest and compare that with OP's comment. If you don't see any problems in vttest, then say so and proceed from there.
As someone who maintains packages, I'd be willing to hear feedback from any source because being aware of them is better than not at all. I can't speak for how wezfurlong ranks these set of potential issues-- if they're worth even investigating for example-- but from the perspective of a person giving feedback, I would find his response as unmotivating.
I've run vttest a few times; one of the biggest issues I have with it is that it isn't a unit test. It relies on a human to know what looks correct and know from what is on the screen what it was trying to do.
If you can concisely describe specific conformance issues, then I'd really appreciate it if you could file a github issue for each one. Please don't just file an issue that says "run vttest", as that isn't very actionable.