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

Phanpy

Minimalistic opinionated Mastodon web client

Mệt mỏi với "thuế SaaS" – giới hạn ký tự, nạp credit, trả phí hàng tháng dù đã sở hữu card NVIDIA mạnh. Giờ tôi chuyển hoàn toàn sang chạy AI âm thanh cục bộ (local inference), không mạng, riêng tư tuyệt đối, không độ trễ, chi phí = 0. Chất lượng mô hình (VITS/Transformers) giờ ngang ngửa đám mây. Kiểm soát toàn bộ hệ thống sản xuất thay vì thuê. Hãy dùng tối đa phần cứng bạn đã trả tiền! #LocalAI #AIVietnam #TextToSpeech #SaaSTax #MachineLearning #TríTuệNhânTạo #AI Âm Thanh #GPU #OfflineAI #NVI
@mwl@io.mwl.io’s post made me revisit RCS in a very small role: a safety net for individual files.
Paired with nvi, a tiny wrapper lets me snapshot configs before risky edits. Simple, local, no magic.

Example wrapper I’m using:

#!/bin/sh
#
# safeedit — RCS-backed safe editing with nvi
#

set -e

if [ $# -ne 1 ]; then
echo "usage: safeedit <file>" >&2
exit 1
fi

FILE="$1"

if [ ! -f "$FILE" ]; then
echo "safeedit: file not found: $FILE" >&2
exit 1
fi

DIR=$(dirname "$FILE")
BASE=$(basename "$FILE")
RCS_DIR="$DIR/RCS"
RCS_FILE="$RCS_DIR/$BASE,v"

mkdir -p "$RCS_DIR"
chmod 700 "$RCS_DIR"

if [ ! -f "$RCS_FILE" ]; then
ci -l "$FILE"
else
ci -u "$FILE" || true
co -l "$FILE"
fi

exec nvi "$FILE"
nvi protects the session; RCS protects the decision.

Original post by https://io.mwl.io/@mwl/115814245521209100

#nvi #RCS #Unix #SysAdmin #ConfigManagement
Michael W Lucas :flan_on_fire: (@mwl@io.mwl.io)

The more I learn about git, the more I appreciate RCS.

Sufficiently Amusing Author
I use git daily, but I’ve started revisiting RCS in a very narrow role: as a safety net for individual files.
Paired with nvi, it works nicely to snapshot important configs before risky edits. Simple, local, easy to reason about.

https://io.mwl.io/@mwl/115814245521209100

#RCS #nvi
Michael W Lucas :flan_on_fire: (@mwl@io.mwl.io)

The more I learn about git, the more I appreciate RCS.

Sufficiently Amusing Author
Quick tip for fellow nvi users: you can “Vim-style format JSON with jq” even in old-school vi.

vim: :%!jq .
nvi: :1,$!jq .

Same idea: filter the whole buffer through jq and replace it.

#nvi #vim #jq #unix #slackware
I’ve updated my nvi cheatsheet with practical examples for startup commands (-c) and classic vi ↔ Unix workflows (!, %!).

The page is a living document, and the RSS feed now tracks updates properly.

nvi cheatsheet: https://4c6e.xyz/nvi.html
RSS feed: https://4c6e.xyz/rss.xml

#nvi #vi #unix #slackware #rss
nvi cheatsheet

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

@r1w1s1 be careful with nvi on GNU/Linux editing arbitrary files. At least the Debian version can lead to unrecoverable data loss if you don’t have a backup.

The longer story: if you set, for example, your user locale to a UTF-8 locale, then the locale-ified nvi (as opposed to the boring old one in ancient OpenBSD) tries to convert multibyte to wide characters on reading. If the file contains an octet sequence that’s not valid UTF-8, this will, of course, fail. #nvi tells you that… when you try to save the modified file, after it has already truncated it to that point.

There are saner editors which allow you to retain, delete, and even edit and create new such sequences in an otherwise UTF-8 (or ASCII) file.

MirBSD: jupp — Programmer’s Editor

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

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
Code Notes

Ricardson's coding notes and guides focused on Unix, Slackware, and minimal systems.