Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by chromas on Wednesday August 22 2018, @09:22PM   Printer-friendly
from the :wq dept.

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."


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by Arik on Wednesday August 22 2018, @09:53PM (4 children)

    by Arik (4543) on Wednesday August 22 2018, @09:53PM (#724888) Journal
    "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,"

    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?
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2, Informative) by Anonymous Coward on Wednesday August 22 2018, @10:17PM

    by Anonymous Coward on Wednesday August 22 2018, @10:17PM (#724899)

    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

    by hendrikboom (1125) Subscriber Badge on Thursday August 23 2018, @12:47AM (#724971) Homepage Journal

    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)

    by DavePolaschek (6129) on Thursday August 23 2018, @01:40PM (#725197) Homepage Journal

    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

      by Arik (4543) on Thursday August 23 2018, @02:31PM (#725214) Journal
      "It was an incredible kludge."

      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?