some new fresh stickers logos are dropped for popular apps and services https://github.com/SAWARATSUKI/ServiceLogos #vim #linux #logos
vim
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
On November 2nd, 1991, Vim was released. Happy cake day, #VIM! Let the celebration start with Vim Easter egg:
Open VIM
Type
:smile
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
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
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
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)
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
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
Looks like #obsidian shot itself in the foot with that webviewer... It looks like many users aren't happy with it. Is it based on #chrome ? What about data and #privacy ?
I love the KISS¹ and *nix approach, one tool for one purpose. Never been a fan of products trying to do everything for you.
Maybe that's why I prefer #vim to #emacs 🤷🏽♂️
¹ Keep It Simple, Stupid. !
Normal people: Lol, she types gibberish.. that's funny.
Vim users: You know, with a macro you could have saved 0.3 seconds on editing that line.
#linux #developers #vim
People ask why I use Neovim.
It's because of amazing plugins like this ⚡
⌨️ **typr**: Typing practice plugin for Neovim with dashboard.
💯 Supports showing detailed stats & configuration!
⭐ GitHub: https://github.com/nvzone/typr
#neovim #vim #plugin #typing #practice #speed #dashboard #terminal #editor #keyboard #commandline
