Discovered this when trying to use a java api to make silent installers for programs that didn't have them.
The solution was to use the java api to move the mouse back and forth over the progress bar.
And I thought browsers highjacking the scrollbar was bad!
Oh the memories of playing with java.awt.Robot...
Applications that wrote a lot to the logscreen were slowed down by it. While writing to stdout is buffered, it seems that the rendering itself runs in the same thread as the application.
Making a selection freezes the terminal and this stops the rendering, allowing the application to run much faster.
Removing the selection (by pressing escape) rerendered the window (and the buffer), and it went back to its original slowness.
I think it was called something like quick edit or similar.
Probably some feature that John requested because he couldn't read some output quickly enough. I don't understand how this can be the default behavior.
155 points - 25.May.2009 https://news.ycombinator.com/item?id=625957
493 points 4.Jan.2014 https://news.ycombinator.com/item?id=7011228
I wonder what the cause is/was.
I'm aware that old PS/2 connectors would interrupt, vs being polled like USB.