vi

FUCK IT

WHAT A WASTE OF TIME

#FreeBSD #vi

Still using nvi on Slackware.

No plugins. No syntax highlighting. Just speed, predictability, and classic vi behavior, even with multi-GB files.

I wrote a short guide explaining why nvi still matters and how its architecture enables fast, low-memory editing.

📄 https://4c6e.xyz/code_notes.html (NVI Editor Guide)
📄 https://git.sr.ht/~r1w1s1/code-notes/blob/main/notes/NVI_Editor_Guide.txt (plain text)

#slackware #editor #nvi #vi #unix #minimalism

TIL again, about low ram footprint editors in OpenSource environments.

In the period where the following commands were valid

ATX3DT
ATA

Such editors were standard. I'm talking about vi. Over extremely noisy POTS lines without error correction, vi was the only editor you could use safely. I remember switching from editing mode to reading mode as frequently as possible, because the 2400 BPS modem from the SR University, had difficulty to keep the line as noise free as possible due to the archaic hardware infrastructure of the phone company.

The editor I'm learning again about is nvi
I'm going to take a deep dive into this, because one thing I love is using the least memory as possible while computing

#vi #nvi #vim #VimMasterRace #editor #SSH #AT #Hayes #OpenSource #programming #Linux #technology

https://4c6e.xyz/code_notes.html

self-report

#unix_surrealism #comic #vim #vi #openbsd #technomage #edisthestandardeditor

I saw this post and it motivated me to do a quick test:
https://phanpy.social/#/hachyderm.io/s/115891592999188880

Stop opening huge files in screen editors.

Screen editors (nvi, vim, etc.) assume you want to scroll,
see context, and move a cursor interactively.
Huge files break those assumptions.

For large files (1GB+):

Inspect: head, tail, grep
Understand structure: awk, sed -n (stream, don’t load)
Surgical changes: ed or sed

Open a screen editor only when you need to rewrite text.

Benchmark (1GB text file):
nvi -> 20.1s (eager line indexing ~25M lines)
vim -> 7.7s (lazy loading, deferred UI cost)
ed -> 4.0s (I/O-bound buffering, no TUI overhead)

Large files don’t need better editors.
They need better workflows.

For huge files, the right solution is not tuning nvi,
but using the right tools:
shell for inspection, ed for known changes,
and nvi when interactive rewriting is actually needed.

PS:
nvi chooses predictability over perceived speed.
The slowdown is not a flaw — it’s the cost of correctness
within a screen-editor model.

#vim #vi #ed #unix #linux #sysadmin