4 ms·

I just saw this and after a quick checkout of the latest release (which is what I can quickly install), I feel a bit disappointed. Here is yet another GPU-accel

I just saw this and after a quick checkout of the latest release (which is what I can quickly install), I feel a bit disappointed. Here is yet another GPU-accelerated terminal that claims to be a VT500 (judging by its Device Attributes report), sets TERM to xterm-256color, while having holes in basic VT100 support (just ran VTTEST in it and saw glaring issues, need not look further than basic VT100 tests, TAB setting/resetting, cursor save/restore). 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.

snvzz 6y ago
zutty is great, and I would use it if it did support double-width characters (needed for CJK, which I need). Alas, it does not.
wezfurlong 6y ago
Thanks for the feedback. Please keep in mind that this project is a free time project, so when you make a generalization that my priorities are wrong and that I have lots of resources, you're a bit off base. 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.
- rirze 6y ago
  I get that this is side project that you do in your free time, but expecting reviewers to "file a github issue for each" problem they find in vttest isn't the right answer. 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.
  - qmmmur 6y ago
    So like... open a discussion where they can discuss specific issues? Do you realise how entitled you sound right now?
    - rirze 6y ago
      Maybe I am entitled. But if I posted a comment like OP and got the same response he did, I wouldn't be bothered to file those issues. wezfurlong's response (imo) came across as defensive and dismissive, while also redirecting any potential discussion. 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.
- dflock 6y ago
  I was looking at zutty, mentioned in this thread - and the website says this: > 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 https://github.com/tomszilagyi/zutty
  - wezfurlong 6y ago
    Thanks for sharing! 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_requests/6 https://gitlab.freedesktop.org/terminal-wg/esctest/-/merge_r...
simias 6y ago
I gave it a try and while I haven't noticed any obvious issue, the fact that it offers multiplexing, serial port and builtin ssh support is a bit of a red flag for me. Oh and apparently it embeds lua scripting? Soon it'll have a built-in email client! 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.
- wezfurlong 6y ago
  You can hate it all you want, I don't mind! 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!

snvzz 6y ago

zutty is great, and I would use it if it did support double-width characters (needed for CJK, which I need). Alas, it does not.

wezfurlong 6y ago

Thanks for the feedback. Please keep in mind that this project is a free time project, so when you make a generalization that my priorities are wrong and that I have lots of resources, you're a bit off base. 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.

rirze 6y ago
I get that this is side project that you do in your free time, but expecting reviewers to "file a github issue for each" problem they find in vttest isn't the right answer. 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.
- qmmmur 6y ago
  So like... open a discussion where they can discuss specific issues? Do you realise how entitled you sound right now?
  - rirze 6y ago
    Maybe I am entitled. But if I posted a comment like OP and got the same response he did, I wouldn't be bothered to file those issues. wezfurlong's response (imo) came across as defensive and dismissive, while also redirecting any potential discussion. 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.
dflock 6y ago
I was looking at zutty, mentioned in this thread - and the website says this: > 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 https://github.com/tomszilagyi/zutty
- wezfurlong 6y ago
  Thanks for sharing! 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_requests/6 https://gitlab.freedesktop.org/terminal-wg/esctest/-/merge_r...

simias 6y ago

I gave it a try and while I haven't noticed any obvious issue, the fact that it offers multiplexing, serial port and builtin ssh support is a bit of a red flag for me. Oh and apparently it embeds lua scripting? Soon it'll have a built-in email client! 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.

wezfurlong 6y ago
You can hate it all you want, I don't mind! 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!