💾 Archived View for splint.rs › slowterm.gmi captured on 2023-09-28 at 16:07:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
The original terminal interface let you type to the computer in a type-writer, and the computer would type back - no screen required, just typed-text. Since then, computers have become so fast that no human could possibly read the text spat back out at the user.
I don't think proper distinctions have been made with a lot of this text. Should I read the output of and update? In this case, is the interface assuming that I should scroll up and read from the top, since nobody could possibly read the real-time output? In this case, should the terminal not have a maximum character limit which guarantees that you can read the output? Or some way to ensure that no more than 3,000 lines of text come out?
We have no standards, and I can't fix that - but one thing we can do it slow the terminal down to the point where one can actually read the output.
Input the following `slow` function to be able to read long text output. Of course it will make a standard upgrade take all day, so I couldn't recommend it for normal use - but at least it looks retro.
function slow(){ mkfifo /tmp/bashpipe 2>/dev/null ( cat /tmp/bashpipe | perl -We 'use Time::HiRes;$|++;while(read(STDIN,$c,1)){Time::HiRes::usleep(15000);print $c;}' )& exec &> /tmp/bashpipe }