Top
Best
New

Posted by hggh 7 days ago

The vi family(lpar.ath0.com)
181 points | 106 comments
nineteen999 5 hours ago|
I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient, since they were developed to work accross a broad range of UNIX systems (SCO, Solaris, HP-UX, OSF, AIX) and I rarely add anything to my vim configs on top of that other than syntax highlighting.

But I'd still rather use it than just about any other text editor, just for the simplicity of that muscle memory alone. I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor.

applfanboysbgon 3 hours ago||
> I have way more stuff to keep in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a text editor.

I can't say I agree. To me this is equivalent to saying "I have way more music in my head than I have room for and I can't afford to expend more than about 0.0001% of context on a piano". The tool you use for 8+ hours a day is extremely important and even small gains will pay dividends over the long run. The more efficiently the text editor allows you to do tasks, the more time you have to think about other tasks.

t43562 2 hours ago|||
He IS saying that. Vi is more efficient for him every hour every day because he has been able to learn it to the point where there is nearly zero effort in using it. To learn something else would be to throw away all that hardcoded memory and try to rebuild it.
rockland 1 hour ago||||
To continue the musical instrument analogy, I already master the piano and I am happy with it solving my requirements. Learning the guitar will be a great undertaking, and provide me no new songs to play.

Hence, I will stick to my piano.

nineteen999 10 minutes ago|||
That's actually funny, because I play both.
applfanboysbgon 1 hour ago|||
They didn't say they mastered the piano, though.

> I consider my vi/vim skills to be extremely minimalist subset, and probably horribly inefficient

Likewise, "I don't configure anything from the default" could be likened to playing an out-of-tune piano because you just can't be bothered. If you genuinely switch machines so often that configuration becomes a burden, sure, stick with the defaults -- but I think it's doing yourself a bit of a disservice if your reason is instead "I don't think it's worth spending time or mental energy on my tools".

Alpha3031 48 minutes ago||
I feel like the closest analogy to leaving everything set to the default would not be an out-of-tune piano but one that you've left in 12-ET instead of retuning it to just intonation in the key you use. Vim on default configs is still a perfectly functionality piano.
fmbb 1 hour ago||||
All pianos have the same interface, no?
mi_lk 52 minutes ago|||
I mean I'm sure some people are crazy efficient with Dvorak keyboard layout, but you can pry Qwerty out of my dead cold hands.
never_inline 13 minutes ago|||
Yeah; I have a minimal vimrc with cursorline, wrap, line number, some other option to make arrow keys jump to next line from end. I set a different colorscheme on each machine when I have to deal with multiple machines. That's it.
piekvorst 3 hours ago|||
I think that it's wrong to assume that vi is the only route to deep muscle memory. Heavy mouse users develop blindingly fast Fitts’ Law targeting. And if you need essential simplicity, they have far fewer commands.

Bill Joy, the original author of vi, saw the vi commands as a problem, not a solution [1]:

    The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing.
[1]: https://web.archive.org/web/20120210184000/http://web.cecs.p...
skydhash 18 minutes ago|||
> Heavy mouse users develop blindingly fast Fitts’ Law targeting. And if you need essential simplicity, they have far fewer commands.

Even if you remember the general placement of things? You still have to consciously track where the pointer is and when it will be on target. I was better with old applications where everything was accessible, bit in this era of low density interface and deep navigation, it’s not great.

The Acme editor is a great example on how to use the mouse. Every click results in an action. And a customizable interface so that you can have what you need at the ready.

0ld 56 minutes ago|||
well, i've got this in my muscle memory too for a reason (that linuxes tend to use vim instead of vi and enable mouse there by default):

:set mouse-=a

bionsystem 17 minutes ago|||
I functionned this way for a very long time, plain vim with 5-6 options in .vimrc, no plugin (aside for the very occasionnal syntax highlighting like jinja.vim iirc). I kept this setup for more than 10 years mainly to stay compatible with multiple systems (in my case Solaris/Illumos, Linux, MacOS and even Windows).

But I made the switch to nvim / LazyVim. And it is actually pretty good. I had in mind those endless hours of config and lua scripting. At the end of the day all I needed actually was to remove a plugin (folke, which messes with my 's' key) and learn to use the package manager to setup the languages I wanted.

Having things like GrugFAR or lazygit at the tip of my finger is actually a quality of life improvement. I could do without those for sure but they fit my workflow and muscle memory well.

Still wish there was something better for ansible ; I should have gone with pyinfra with my current job's project but I only learned about it after writing 12k LoCs of ansible :'(

rmunn 4 hours ago|||
I never edited the default config much.

But then I discovered https://www.lazyvim.org/. Turns your copy of NeoVim into an IDE.

I still haven't edited the default config much, actually. But now I'm probably 2x to 3x as productive in vim (nvim, now) as before.

P.S. If you decide to check out the LazyVim config, I highly recommend reading https://lazyvim-ambitious-devs.phillips.codes/ all the way through. There's a lot of new keybindings to learn, but Dusty Phillips's book gives you a gentle on-ramp to learning most of them.

rmunn 3 hours ago|||
I should mention what is becoming my favorite thing about LazyVim's default config, which is the "flash" or "seek" command (LazyVim maps it to `s` so I think of it as "seek") from https://github.com/folke/flash.nvim. I didn't like it at first as I was used to typing `s` to quickly replace a single character with a bunch of text (as opposed to `r` which replaces it with just one character). But I soon learned to remap my brain to use `cl` where I used to use `s`, and then I learned to love "flash"/"seek" mode.

I wrote about how it works in https://news.ycombinator.com/item?id=48118585 so I won't repeat that here. But if I had to pick my favorite feature from LazyVim's config... well, actually it would probably be something else, but `s` is definitely in the top three by now.

plomme 2 hours ago||
Flash is amazing, and what made me drop VSCode. Flash feels like an innovation and basically lets me move my cursor at almost the speed of thought. Highly recommend people try it out and play with it!

BTW: The Vimium extension [1] for Firefox has a similar mode for links called "linkHinting" which I've mapped to s[2] for a similar experience in the browser :)

[1]: addons.mozilla.org/en-US/firefox/addon/vimium-ff/

[2]: `map s LinkHints.activateMode`

mrweasel 3 hours ago||||
The demos of LazyVim looks really nice, and people seem to get a benefit/joy out of it. I gave it a try, but it's a little to much for me.

Right now I think my .vimrc is two lines. That's also sort of silly as I benefit very little from all the things Vim can do.

jauntywundrkind 3 hours ago|||
I similarly thank the stars I ran into AstroNVim, which itself is based on LazyVim. Out of the box it has a lot of well integrated/just works pieces. It has a bunch of leader key things setup, and, crucially, a little visual navigator at the bottom of the screen. Going from powerful but invisible to having something I could see was such a help! I'd compare it to moving from tmux to zellij but I'm a pretty happy tmux user. https://astronvim.com/

What really seals the AstroNVim deal for me though is the community packs. People have very thoughtfully integrated support for a huge range of nvim plugins. And it's super easy to install, and they often fit in nicely to the existing out of box experience of nvim. https://github.com/AstroNvim/astrocommunity

mehalter 30 minutes ago|||
Hey, AstroNvim core maintainer here! Just wanted to clear something up. AstroNvim is in no way based on LazyVim, AstroNvim existed for almost 2 years before LazyVim existed...
lcvriend 1 hour ago||||
Yeah, I have also been really impressed with AstroNVim. I tried using LazyVim for quite some time but I kept having a hard time getting used to it. Somehow I kept tripping up when trying to do things.

On one of my servers I needed to disable icons which AstroNVim handles very conveniently (https://docs.astronvim.com/recipes/icons/#disable-icons). After switching I noticed that using AstroNVim feels so much more natural to me. It's been a joy to use.

I think it might be because the defaults are less bespoke and it's just a bit leaner. The community packs have also been great for customization.

ethagnawl 3 hours ago|||
> that muscle memory

Once in a while I will mistakenly dump a string of keystrokes into insert mode or another application. That literal output always amazes me because the construction of those strings is so far removed from my brain's "main thread".

The inverse is if I try to write a helper function or explain to someone else how I did something they observed and I need to methodically document each action. It's like trying to describe how to walk or something.

userbinator 4 hours ago|||
Likewise, I'm also not very demanding of my text editor. I used vi on any *nix systems and Notepad (the original one, not the new bloated monstrosity) on Windows for most of my work. Navigation, basic editing, and searching are probably all I need.
elektrontamer 5 hours ago||
Same. I barely edit default configs. I also mostly use emulators provided by whatever ide I use.
ventana 5 hours ago||
One thing I noticed that with Claude Code and Codex running in the terminal, I tend to use VS Code much less than before, and found myself opening files in vim more often. It just looks like, for me, the agent development brings me back to using the basic tools, like many years ago, before VS Code existed.
JohnMakin 4 hours ago||
This is interesting to me. vim was my main editor since the start of my career and I was very fast with it, much faster than my peers with an editor. at the outset of llm’s, I ended up using a plugin that would utilize bindings to help me edit faster. with claude code, and how fast it is making changes across many files, I almost never use vim anymore, or vi, unless I need to inspect files in a container/server.
avadodin 1 hour ago|||
Funny, because the only reason I fire up VSCode is to chat up the bots because we are AI-compliant now and the customers pay for it.

I tried nvim integration but it was half-baked and I can't even use nvim as an editor because they removed cscope support. nvi back in the day also dropped support for cscope because it wasn't vi enough. Hell, there is barely a working source repository for it. Only vim supports it out of the box. Am I the only person using cscope in 2026?

As of current day, I only use vim with no plugins to edit source code.

raimo 5 hours ago||
Yes indeed, same here!
be_erik 6 hours ago||
The history and endurance of vi is impressive. I never thought I would be using the same editor today that I started using in the mid 90s because it was more l33t.

The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.

NewsaHackO 15 minutes ago||
Yes, it almost feels like inserting politics to an otherwise apolitical discussion. Just unnecessarily charges the discussion and makes one not want to engage with the article.
normie3000 5 hours ago|||
> The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.

The existence of vim classic would be hard to explain without reference to LLMs.

berkes 2 hours ago||
yes, but that could've been part of the explanation in vim-classic. Other attributes and reasons for improving/forking are explained in the entry of the fork.
rmunn 6 hours ago|||
I started learning vi around the same time, but in my case (since I was expecting to work on Unix systems for decades, which has proven true) it was "because it'll always be there." I.e. if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there (perhaps the problem you're fixing is that /usr isn't mounting), but you can nearly always count on /bin/vi being available: if you can access the server at all, you will be able to access vi, so at least learn its basic keystrokes, our prof told us.

That advice was not entirely accurate (sometimes vi is in /usr/bin/vi, for example), and the merging of /bin with /usr/bin has made it kind of a moot point. (EDIT to add: Though the fact that busybox includes a basic vi implementation has kind of un-mooted the point, actually). But I first started learning vi because I figured I would need it professionally, and when the modal-editing workflow "clicked" for me, I figured out that I had just learned the editor I would want to stick with for years.

And although vim replaced vi and nvim replaced vim in my finger-macros, that has remained true to this day.

sgtlaggy 5 hours ago||
> if you're SSHing into a server to fix a problem, it's possible that /usr/bin/emacs won't be there

You don't need emacs on a server. TRAMP is built-in and can open remote files in a local instance over SSH, SMB, FTP, ADB, or docker/podman.

owl57 2 hours ago|||
I often use vim despite knowing only a few basic commands because I'm already running various commands on the remote machine in the terminal and don't want the context switch. And because connection / file path completion in TRAMP is annoyingly slow if the server is far enough.

As an extreme example, today I needed to combine parts of two files into one and decided that

  cat foo bar > foobar && mv foobar bar && vim bar
of all things will better keep me in the flow than either googling how to insert one file into another in vim or starting up TRAMP.
pmontra 5 hours ago||||
Yes, I can use TRAMP but as I ssh to the server anyway to run commands, I'm editing the files with vi there. Furthermore I'm sure I don't inadvertently edit the local version of the file instead of the remote one, or that I forget to kill the buffer with the remote file and edit it instead of the local one after a few days. What's on the server stays on the server.
rmunn 5 hours ago|||
Never really learned emacs so didn't know TRAMP existed. When was it created? I was given that advice ("vi will always be available on the server") in the late 90's so I'm curious to know if TRAMP was an option my prof didn't know about (or didn't mention), or whether it was developed later and the advice was good at the time.

EDIT: Found http://www.fifi.org/doc/tramp/tramp-emacs.html which mentions that TRAMP started development in November 1998. I would have been getting that advice in late 1997 or early 1998, given when I started my Unix class at college. So the answer appears to be that the advice was actually correct at the time, but superseded sooner than I thought it was.

scbrg 2 hours ago||
Well, TRAMP was preceded by ange-ftp, which let you edit files remotely over ftp. I was using that in 1995, and I didn't get the impression then that it was brand new, so it had probably been around for a while already.

Of course, if your problem is "/usr won't mount", then it's likely that the ftp server isn't running either, so the advice still makes sense.

ethagnawl 3 hours ago|||
The inclusion of comments about LLM generated code don't bother me and will probably be quite revealing (for better or worse) when people read this post in the future.

Also, I have not been following the d2d development of vim closely after Bram's passing but I can't help but wonder what he'd have thought about this approach to development of vim.

Scarbutt 6 hours ago||
The comments about LLM contributed code seems like a specific axe to grind that otherwise detracts from a nice history lesson.

Seems like an interesting fact for those who don't follow the development of vim/neovim.

helterskelter 4 hours ago||
If anyone wanted to write a minimal vi-style helix clone they should call it 'ix', as it's derived from helix, gives a nod to 'vi' and a wink at the turning of vi syntax on its head, like rotating a six to make a nine. Then a descendent of 'ix' could be called 'six', and we'll have come full circle.
creshal 2 hours ago|
Jokes aside, I don't really see the appeal of a demake of helix; it only really makes sense to me as "vim but far more concepts integrated as first-class features rather than addons"; take that away and you have vi with less muscle memory. So, kakuone with the serial numbers filed off.
pjmlp 2 hours ago||
> If you’re wondering why so many people would choose to use a fifty year old text editor with a notoriously steep initial learning curve, it’s because once you learn it, you can be ruthlessly efficient with your editing.

I have learned it back in Xenix heyday, and decided I was better off with Emacs.

Unfortunely not every server has Emacs pre-installed.

On my own devenv I would rather reach out to IDEs, that replicate as much as possible the Xerox PARC / Symbolics / TI experience.

isolli 2 hours ago|
I, for one, am happy that every terminal I've ever used still supports Emacs shortcuts. Useful, for instance, to cut a whole line and paste it later on (ctrl+k, ctrl+y).
elch 2 hours ago|||
Those are not terminal shortcuts. They are program shortcuts. E.g. bash supports Emacs command line editing shortcuts using GNU Readline library. But the library (and bash) support vi mode editing too. POSIX sh(1) specifies vi-mode command line editing only.
pjmlp 2 hours ago|||
Agreed.
elxr 1 hour ago||
Helix, although a bit barebones by default, has been so much nicer for me recently than any of the vi editors so far. Love the default motions so much more, and having multi-cursor adds so much to the day to day experience.

Helix mode in zed is closest to my perfect text editor right now. Does everything helix does but with alt-up/alt-down to move lines, and a few other little things like that that you'd expect a modern editor to have.

grebc 6 hours ago||
Interesting the history is varied for such a simple tool.

I am but a lowly mouse/GUI user so rarely have to dwell in a shell, but I learnt the basics of vi in my 1st year of university and never forgotten. Gotten me out of many a pickle being able to reliably edit a file quickly.

ivanjermakov 3 hours ago||
Simple tool? Visual text editor is probably the most complicated piece of software in coreutils.
elxr 1 hour ago|||
Neovim supports the mouse by the way.

I'm a GUI user too but using helix-mode (like vim-mode but IMO more intuitive) in my GUI editor, zed, gives me the benefits of both.

normie3000 5 hours ago||
...and presumably quit vi once you're done!
rmunn 4 hours ago||
I have typed either :wq or ZZ into so many files in VS Code... :-)
tmtvl 56 minutes ago||
I used Vim for about 5 years until the fact I had to smash the living daylights out of every key started to really take its toll on my hands. I then tried Atom for a bit (requiescat in pace) before landing on Emacs. Which is funny: switching FROM Vim TO Emacs in order to combat RSI, usually it's the other way around.
nixass 4 hours ago||
Few days ago I watched a video where a guy wrote the code for Linux USB driver from scratch. In frickin' vi! It was a ride
submeta 3 hours ago|
And he doesn’t use any config it seems. No syntax highlighting, no line numbers, plain white text on dark background.
4ggr0 24 minutes ago|||
he did however decide to use a font which gives off comic sans vibes, which is a very interesting choice for an otherwise very barebones setup :D
nixass 3 hours ago|||
Exactly, it's wild!

If anyone wants to have a look: https://www.youtube.com/watch?v=IXBC85SGC0Q

Correction, the driver is specifically for Apple Xserve front-panel

S0und 1 hour ago||
What is also wild is that the video has 2.5M views, very odd.
elch 1 hour ago|
Debian is using this upstream repository for nvi and UTF-8 is supported.

https://repo.or.cz/nvi.git

More comments...