Glimpses of very fast output can still be read by persistence of vision while staring at one part of the screen (you can still get a sense of what's being compi

Glimpses of very fast output can still be read by persistence of vision while staring at one part of the screen (you can still get a sense of what's being compiled at the moment, for example), which added motion blur would defeat. Maybe a terminal feature like `less -w' where a status column shows a (potentially motion-blurred) indicator of the amount scrolled in each frame could make the best out of both use cases. Related personal observation: A higher refresh rate increases the max scroll speed where text tracked with the eyes is clear enough to read, but decreases the legibility of fast output read by persistence of vision. When I tested this – the store employee was rather puzzled at this use case – 60Hz seemed to be optimal. At 120Hz or higher, scrolling text was (edit) less comprehensible at the same output rate. This applied to various panels and drive modes. I've never used a high refresh-rate CRT, but I surmise they don't t differ here, since CRT flicker only reduces motion blur that is itself caused by eyes smoothly pursuing onscreen objects made of stationary frames. Edit: Speaking of scrolling UX, I wish browsers had the option to "overscroll" when paging down, so the unread portion always starts at the top of the screen, as implemented in https://news.ycombinator.com/item?id=36825027 https://news.ycombinator.com/item?id=36825027. You can make less do this with `-c' (not at all evident from the documentation). A userscript, perhaps...