nvi

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

Today in #FreeSoftwareAdvent, I realized how much my daily setup changed over the years.

I removed my external monitor and keyboard.
Not to be minimalist, but to reduce context switching.
I kept the mouse because speed still matters.

Working sometimes from my parents house made it clear that relying on an external monitor was fragile, so I forced myself to work only with the laptop.

The same thing happened with software.
Vim slowly became nvi.
Alacritty became xterm, then st.

I didn’t look for lighter tools, but for ones I could trust and reason about. Less abstraction, fewer surprises.

Today I use two identical laptops -- one for work, one personal -- same setup, side by side, one mouse for each.
The environment disappears, and the work stays.

#suckless #st #nvi #xterm

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 screen editors,
but using the right tools:

shell tools for inspection
ed for known, surgical changes
screen editors when interactive rewriting is actually needed

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

#vim #nvi #ed #unix #linux #cli #sysadmin