Mastodawn

Undo in Vi and its successors

So vi only has one level of undo, which is simply no longer fit for the times we live in now, and also wholly unnecessary given even the least powerful devices that might need to run vi probably have more than enough resources to give at least a few more levels of undo. What I didn't know, however, is that vi's limited undo behaviour is actually part of POSIX, and for full compli

https://www.osnews.com/story/144459/undo-in-vi-and-its-successors/

#Unix

Undo in Vi and its successors – OSnews

Show thread

jmcunx Feb 19

@osnews

Well, learn something new every day :)

I just tried this on #NetBSD and it worked as described. Since #slackware now has nvi, it will be interesting for people there too.

#unix

Show thread

r1w1s1

I gradually stopped using Vim and now use nvi exclusively. I even wrote a small quick reference for it:

http://www.slackware.com/~r1w1s1/nvi.html

CC: @[email protected]

#slackware #nvi

nvi Quick Reference

Show thread

jmcunx Feb 20

@r1w1s1 @osnews

One thing I noticed about #nvi as opposed to #vim. #nvi is able to edit very large text files, were #vim can take a much longer time to load that file for edit. That is because it seems #vim reads the full file into memory, were #nvi seems to reads portions into memory.

But to be fair, no one in their right mind would edit a file as large as I am referring to :) But I have done it a couple of times due to database loads at work.

Show thread

r1w1s1 Feb 20

This came up before in a discussion about nvi vs vim on large files.

I ended up writing a short note on it:
https://git.sr.ht/~r1w1s1/code-notes/blob/main/notes/Stop_Opening_Huge_Files_in_Screen_Editors.txt

The short version: both editors pay a cost at scale, just at different moments. nvi does eager line indexing upfront, vim defers it but neither eliminates the cost. For truly large files, the right answer is usually ed, sed, awk, or grep rather than any screen editor.

CC: @[email protected]