Speed is far from the only thing that matters in terminal emulators though. Correctness is critical.
The only terminals in which I have any confidence of correctness are xterm and pangoterm. And I suppose technically the BEL-for-ST extension is incorrect even there, but we have to live with that and a workaround is available.
A lot of terminal emulators end up hard-coding a handful of common sequences, and fail to correctly ignore sequences they don’t implement. And worse, many go on to implement sequences that cannot be correctly handled.
One simple example that usually fails: \e!!F. More nasty, however, are the ones that ignore intermediaries and execute some unrelated command instead.
I can’t be bothered to pick apart specific terminals anymore. Most don’t even know what an IR is.
As someone who had to develop on a super-restricted, underpowered laptop: Speed meant a LOT to me. Being able to think faster than my laptop, because I was using vscode’s terminal (which is Electron based), was excruciatingly painful - Wezterm FTW! I used Alacritty, but due to windows versions pasting indented text made Alacritty indent more and more, which was a frustration for me.
But I would agree that beyond a certain point speed won’t matter, because when your machine can be powerful enough to run vscode smoothly, that (Electron) won’t matter any more.
Anyway, I fully agree with you; I just wanted to note that depending on the situation, speed may matter a LOT more than some may think :)
True, speed does matter somewhat. But even if xterm isn’t the ultimate in speed, it’s pretty good. Starts up instantly (the benefit of no extraneous libraries); the worst question is if it’s occasionally limited to the framerate for certain output patterns, and if there’s a clog you can always minimize it for a moment.
Speed is far from the only thing that matters in terminal emulators though. Correctness is critical.
The only terminals in which I have any confidence of correctness are
xtermandpangoterm. And I suppose technically the BEL-for-ST extension is incorrect even there, but we have to live with that and a workaround is available.A lot of terminal emulators end up hard-coding a handful of common sequences, and fail to correctly ignore sequences they don’t implement. And worse, many go on to implement sequences that cannot be correctly handled.
One simple example that usually fails:
\e!!F. More nasty, however, are the ones that ignore intermediaries and execute some unrelated command instead.I can’t be bothered to pick apart specific terminals anymore. Most don’t even know what an IR is.
I’m glad I’m not a terminal emulator or I’d feel personally attacked.
As someone who had to develop on a super-restricted, underpowered laptop: Speed meant a LOT to me. Being able to think faster than my laptop, because I was using vscode’s terminal (which is Electron based), was excruciatingly painful - Wezterm FTW! I used Alacritty, but due to windows versions pasting indented text made Alacritty indent more and more, which was a frustration for me. But I would agree that beyond a certain point speed won’t matter, because when your machine can be powerful enough to run vscode smoothly, that (Electron) won’t matter any more.
Anyway, I fully agree with you; I just wanted to note that depending on the situation, speed may matter a LOT more than some may think :)
True, speed does matter somewhat. But even if
xtermisn’t the ultimate in speed, it’s pretty good. Starts up instantly (the benefit of no extraneous libraries); the worst question is if it’s occasionally limited to the framerate for certain output patterns, and if there’s a clog you can always minimize it for a moment.