4 ms·
st is superb. Other terminals have more features (that I don't care about). Kitty is well thought-out, but Kovid has a lot of strong opinions that cause all s
by georgia_peach 4y ago
st is superb. Other terminals have more features (that I don't care about). Kitty is well thought-out, but Kovid has a lot of strong opinions that cause all sorts of problems with common software (like vim & tmux). Wezterm is also a fine piece of work, but the constant upgrade notifications turned me off. xterm is a classic, but the .Xresources / xrdb dance gets to be a pain.
- greyw 4y agost has the highest input latency among quite a few terminal emulators [1] and feels thus very slugish. It's an ok piece of software at best. [1] https://danluu.com/term-latency/ https://danluu.com/term-latency/
- georgia_peach 4y agoIt's not a video game. I type programs in it. 30-110 ms is more than fast enough.
- greyw 4y agoThe terminal emulator is probably the most used and most important software I'm running. It needs to be enjoyable. I personally can feel the lag so its not good enough for me. Anyway that being said I have some collegues that are not bothered by lagging mouse cursors and other janky stuff so I can somewhat understand that this might not matter to some people. edit: I just tried out st again on my gnu/linux machine and it seems to be fine with respect to input latency so I guess its not all too bad of a terminal emulator. Maybe it only sucks on macOS.
- georgia_peach 4y agoIt's probably what ninjin said -- XQuartz latency. I use it on Debian, and speed-wise, I can't tell the difference between st & the GPU-accelerated terminals. On Mac, I switched from iTerm2 to Apple's built-in terminal. It sips battery compared to all of the others.
- ninjin 4y agoI have used urxvt, st, and Alacritty extensively and I would say that to me they feel “snappy” in exactly that order. You are of course welcome to pick whatever metric you want to judge a piece of software, but I can not say that I have ever been bothered by st’s input latency. The input handling is done using XEvent and a call to pselect in x.c and I am sure a patch that does not increase the code complexity massively would be accepted upstream. Luu also had this to say about the experimental setup for st: > st on macOS was running as an X client under XQuartz. To see if XQuartz is inherently slow, I tried runes, another "native" Linux terminal that uses XQuartz; runes had much better tail latency than st and iterm2. Maybe it matters, maybe it does not. But I feel like picking your terminal comes down to a lot more than a single metric and input latency experiment.
- AlanYx 4y agost is such an outlier in those measurements that it makes you wonder whether something is potentially wrong with the test setup. There's another set of latency measurements here: https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty https://tomscii.sig7.se/2021/01/Typing-latency-of-Zutty In those, st is roughly similar in performance to urvxt and Alacritty.
- Beltalowda 4y agoAlso some measurements over here, which are yet again different: https://lwn.net/Articles/751763/ https://lwn.net/Articles/751763/ I guess accurately measuring latency is hard.
- petepete 4y agoI use kitty with tmux all day every day and haven't run into any problems that affect me. The only thing I'm aware of that doesn't work is kittens inside tmux.
- georgia_peach 4y agoIt was a couple years ago last I used it, & had issues with the xterm-kitty identifier, bold-bright vs. bold-thick, and the latest one gives me the following message when I run vim: > [PARSE ERROR] The application is trying to use xterm's modifyOtherKeys. This is superseded by the kitty keyboard protocol: https://sw.kovidgoyal.net/kitty/keyboard-protocol/ https://sw.kovidgoyal.net/kitty/keyboard-protocol/ the application should be updated to use that