Hacker News Reader

Comment by arcanemachiner | Hacker News Reader

I can only hope you're referring to network latency...

I remember that urxvt used to be much more comfortable to use than some other terminal emulators whenever a process was spewing out thousands and thousands of lines of text. Some other terminal emulators at the time were very slow because they printed each and every line. urxvt on the other hand would skip printing lines to keep up. This was much preferable. If I intended to look at thousands of lines of text I would do so through a pager. So printing out thousands of lines of text directly into the terminal was almost always by accident.

I have since gotten better at not accidentally printing a bunch to my terminal, so I am no longer using urxvt these days. But for a period of time urxvt was my preferred terminal emulator for that reason.

I had this discussion with someone on here the other day who flat out believed I'd invented the problem.

Kitty is so fast compared to anything else I've tried.

> urxvt on the other hand would skip printing lines to keep up

Really?

That's a fatal flaw. Skipping lines is never ever OK for a terminal emulator.

Not keeping up can also be a fatal flaw of course!

It’s not a flaw, it’s by design.

https://man.archlinux.org/man/urxvt.1

> -ss|+ss

> Turn on/off skip scrolling (allow multiple screens per refresh); resource skipScroll.

> […]

> skipScroll: boolean

> True: (the default) specify that skip scrolling should be used. When receiving lots of lines, urxvt will only scroll once in a while (around 60 times per second), resulting in far fewer updates. This can result in urxvt not ever displaying some of the lines it receives; option -ss.

> False: specify that everything is to be displayed, even if the refresh is too fast for the human eye to read anything (or the monitor to display anything); option +ss.

Flawed design is still a flaw.

I'll accept that it is a design feature to get around another failure mode, and that it might even be preferable sometimes.

But it's a serious flaw. Terminal emulators should never drop output, that's what control flow signaling is for!

It’s not a flaw. It’s a different kind of use-case than you have in mind.

It’s fine. No one is telling you to use urxvt. You can continue to use whatever terminal emulator you prefer. That’s the power of choice we have. Different programs that do the same kind of things but in different ways.

So there is no reason to insist that urxvt is flawed.

So, yes this has veered strongly into preferences and semantics.

But the job of a terminal emulator is to act as a terminal. Terminals don't drop output in normal operation. That's a failure mode, and maybe it's reasonable or even acceptable.

But the output is imperfect. Imperfections are flaws.

I'm not trying to convince anyone of anything here. Horses for courses, of course.

I'm just surprised to learn that any terminal emulator developer decided that "giving up" is OK. I am sure the other options I can think of were also all considered by the developers, but I'm still surprised.

Probably not. There are terminals with surprisingly high latency, even on modern hardware.

See here for examples of ~100 ms of local latency: https://www.lkhrs.com/blog/2022/07/terminal-latency/

Nope. Alacrity is probably the terminal emulator that revealed this, but terminal emulation itself is sometimes there bottleneck and GPU acceleration is required to get around the problem.

Reply on news.ycombinator.com