Over at The New Stack is a brief but entertaining history of the editor vi and Vim.
"The editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore," Joy said. "It was a world that is now extinct. People don't know that vi was written for a world that doesn't exist anymore."
(Score: 3, Informative) by Arik on Wednesday August 22 2018, @09:53PM (4 children)
Ok, there's some truth to that. Remote terminals can have significant lag (but that hasn't changed much!) But it's really deceptive. In fact, VI running locally on an old frame-buffer to a monochrome display is *not* noticeably slow by todays standards - it's actually *faster* than it might run on more modern hardware going through a high-resolution bitmapped display system with all the excess overhead of a window manager and so on loaded.
And that's all really kind of missing the point anyway. One of the best features of VI/M is that it doesn't *need* a display that can keep up with what you're doing. No program really does, if it's written right. The loop that responds to keystrokes is the highest priority, the screen update code can and should be interrupted freely to keep up with the input. Whenever the input stops, then it's time to work on the screen. There's absolutely no need to bother displaying intermediate steps while I'm still giving you input.
If laughter is the best medicine, who are the best doctors?
(Score: 2, Informative) by Anonymous Coward on Wednesday August 22 2018, @10:17PM
WYSIWYG may be good for quickly learning basic commands, but like LATEX, computers are better suited for the grunt work of formatting.
I worked with a physicist at los alamos who was very good with both Tex ad vi. It was impossible to follow him as he reworked his entire paper - just a bunch of screen flashes, blocks disappearing, reappearing for a few minutes. After which a whole new paper magically appeared, perfectly formatted.
(Score: 2) by hendrikboom on Thursday August 23 2018, @12:47AM
I once wrote and used a screen editor that got used over a 300-baud telephone line. I could type as fast as I was capable of typing. After each keystroke, the editor would calculate what the screen ought to look like, calculate the minimum scrolling motions that would put the lines in right place and then proceed to insert or delete text into those lines, giving priority to the ones I was working with. It worked pretty well.
(Score: 2) by DavePolaschek on Thursday August 23 2018, @01:40PM (1 child)
Even more fun was "rvi" which was a retro-separation of the "draw stuff on a screen" from the "do the editing using ed" back end. The version I used was distinct from the later "vim --remote" but may have inspired it.
300 baud connection to the server mostly felt fast enough as long as you had a reasonably snappy computer running the screen-editor portion. And yeah, your typing and sending editing commands off to the server was the highest priority. Next was the "pulling down lines from the server so I can display them" loop. It was an incredible kludge.
(Score: 2) by Arik on Thursday August 23 2018, @02:31PM
I guess this is where we disagree.
It's not a kludge. It's good design.
I miss it every day, in programs that are so poorly designed they're ignoring my input while trying to push out unneeded (and unwanted) screen updates that never needed to happen at all, let alone as interrupts.
If laughter is the best medicine, who are the best doctors?