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.
> 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.
In particular I really struggle to understand the point of the ssh interface given that ssh already supports multiplexing built-in with ControlMaster.
What happened to "do one thing and do it well"? Make me an ultra-fast minimalist terminal, then I'll use tmux, ssh and kermit if I need them. Focus on handling all the many, many corner cases that you need to implement for accurate terminal emulation.
Well, I guess I'm turning into a bit of a hater here, I guess I'm just frustrated that it's not the project for me. Hardware accelerated Rust terminal hyped me a little too much I suppose.
ssh support is present because Windows' pty story, while better than 5 years ago, isn't great. The integrated ssh support allows bypassing that layer when running wezterm on Windows and connecting to a real unix system.
serial port support is present because I do a lot of embedded work on multiple systems and want a consistent environment.
Multiplexing is there because that is actually what you're building when you add multiple tabs, windows and panes.
You can, of course, not use any of those features and still potentially enjoy using the ones that you do need/want. Or just not use it; I don't mind!
Please note that I am not attacking wezterm here, my criticism is aimed to be constructive because terminals are important. I think wezterm is a very cool project, and I wish all the best to it, but why not make a terminal that actually (correctly) implements those escape sequences? (We are talking about a couple dozen controls here.) Given the development history (3+ years, 3k+ commits) I would say that this is not a resource issue but a prioritization issue.
For an example of a GPU-accelerated terminal with much less polish, less unicode/ligature support and less portability, but one that takes fundamental correctness very seriously (coupled with excellent performance and very low latency) in a tenth of the source code and (presumably) a mere fraction of development resources spent on it, take a look at zutty. Note, if you like wezterm, you will probably NOT want to switch to zutty, because it's a much more basic program.