Rendered at 21:53:12 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
40four 11 hours ago [-]
I’ve been a long time vim user, and I honestly never really bought into the efficiency claims. That gets repeated over and over, but If you’re a slow typer then no editor can really make much of a difference, and development in reality is a lot of reading code and thinking about code when it comes down to it.
I’ve never used it because I thought it would make me some lightning fast super developer. I’ve always used it because it’s simply fun. It’s makes editing into this interesting sort of game. You start out with a simple set of skills from vimtutor, and inevitably brute force your cursor around the screen for a while. Little by little your movements become more complex and efficient, and the journey to figuring that out is fun and interesting.
It makes you think about typing in a totally different way. It makes it into a some kind of interesting game where your goal is to accomplish a task in the fewest keystrokes possible. That problem solving aspect scratches an itch inside my brain that has always kept me coming back. It’s just fun, and I don’t think that gets talked about enough
Cyph0n 46 minutes ago [-]
Vim is definitely more efficient when it comes to navigation and manipulation (esp via macros), which are the two things we do the most as programmers.
The added benefit I found is that Vim’s purely keyboard based design is much, much easier on the wrists. Heck, I pushed myself to learn Vim because I started to feel wrist pain due to KB and mouse switching.
ghtbircshotbe 9 hours ago [-]
That's fair, although now and then I have to do some repetitive task and using bufdo or a macro has saved a decent amount of time. And compared to something like notepad, all the little details probably save time. My average time savings has probably increased significantly after I stopped spending a lot of time creating custom vim scripts and syntax files.
wisemanwillhear 6 hours ago [-]
I like vi/vim, but it gets me all too frequently because I'm not precise enough of a typist. I'm busy typing away and I hit the wrong modifier key or hitting caps lock and I end up pulling things up or making changes that I never intended to make. Worse, in the split second after it happens and my muscle memory tries to correct it my immediate intuition of what mode I was in is wrong or which modifier key I'm pressing or caps lock is on and I only make the situation worse. Any improvements in performance because of the quick key interface are long gone.
psadauskas 6 hours ago [-]
I don't think it makes me more efficient at writing code. Its because the act of coding is like 80% reading existing code, only rarely adding new code. You spend far more time moving around and exploring the code, and in vim the keys to do that are single keypresses, or sequences like `]p`. Every other non-modal editor requires you to hit chords like Ctrl-Shift-F to move around, because the "easy" keys are all taken up by "add this character to the buffer", 100% of the time.
asdfsa32 10 hours ago [-]
It is fun because it is fluent. vi has a language.
coldpie 8 hours ago [-]
If I spend more than a couple minutes in an arrow-keys-and-mouse text editor, I often find myself unconsciously reverting to vi-language and getting confused. "Oh, I want to go change that sentence up the page that starts with 'Looking at...'" so I type "?Looking at" into the text editor and then stare at it for a few seconds before hitting backspace and reaching for the mouse like a caveman.
linsomniac 8 hours ago [-]
I like to think of it more like a bytecode.
alecco 6 hours ago [-]
> never really bought into the efficiency claims
Macros, dude.
It's a bit annoying to become disciplined in text structure/regularity to have macros work flawlessly, but it's a bliss afterwards.
And then... recursive macros.
(I know Emacs has better macros but vim macros are way easier and fun for everyday use).
mpalmer 10 hours ago [-]
I’ve been a long time vim user, and I honestly never really bought into the efficiency claims. That gets repeated over and over, but If you’re a slow typer then no editor can really make much of a difference.
Little by little your movements become more complex and efficient, and the journey to figuring that out is fun and interesting.
The slight contradiction in your comment has a lot of truth in it.
It’s just fun, and I don’t think that gets talked about enough
Yes yes yes. Vim can absolutely lead to more efficient text editing, but I agree it has more to do with the fun journey than with typing speed.
vi definitely doesn't scratch that "itch" for everyone in the same way. But for me, it's as though I found a cheat code. Getting better at vi feels like getting better at a game - only practicing this game makes you better at any number of tasks that are relevant to your daily work.
(although if you also want to get better at typing speed, there are surprisingly fun roguelikes on Steam for just this purpose)
bcjdjsndon 9 hours ago [-]
> practicing this game makes you better at any number of tasks that are relevant to your daily work.
Vi key bindings don't apply outside of vi
Lio 7 hours ago [-]
That's not true at all. Many readline and terminal based clients support vi bindings, you just have to enable them. e.g. stuff like psql.
The shells themselves also support vi binding.
Outside of the terminal tools like Vimium add support to browsers and many other interfaces.
shagie 8 hours ago [-]
I learned vi key bindings in rogue, hack, and moria (before numpads were common for that binding to be default) before I learned them in vi.
mpalmer 9 hours ago [-]
Thankfully my work applies inside vi.
nineteen999 17 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 15 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 14 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.
jmathai 11 hours ago [-]
Learning how to use a proper IDE is a change in workflow.
I never made that switch. The muscle memory of 2 decades of using a software is under appreciated.
For me, it is about preference for what to optimize for.
t43562 11 hours ago [-]
I have tried making that switch many times and lasted for a few months and then one day I find I've been back at the CLI for a week without noticing.
I love CLI tools that effectively give me the things an IDE would offer such as astgrep for refactoring for example. zoekt with a browser does pretty good indexed searches. fzf can be used to build up almost any useful way of selecting things that you can imagine. So the CLI becomes my IDE.
ulbu 11 hours ago [-]
IDEs made the mistake of locking the user into desktop-traditional keybinding paradigm instead of using a more flexible one which would allow for implementation of both vim and desktop paradigms.
(don’t respond with “well they have vim mode plugins”. no they don’t. they’re hacky and unreliable)
loloquwowndueo 11 hours ago [-]
My usual saying is that if all you wanted from vim was a few keybindings, you weren’t really using vim’s capabilities to any extent that matters anyway.
agumonkey 9 hours ago [-]
[dead]
rockland 13 hours 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.
applfanboysbgon 13 hours 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 12 hours 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.
nineteen999 11 hours ago [-]
That's actually funny, because I play both.
loloquwowndueo 11 hours ago [-]
Show off :)
nineteen999 1 hours ago [-]
I didn't say I was any good at them! Just like my text editor.
fmbb 12 hours ago [-]
All pianos have the same interface, no?
12 hours ago [-]
piekvorst 15 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.
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
skydhash 11 hours 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.
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 15 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 14 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 :)
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.
hirvi74 7 hours ago [-]
I am with you on that one. I use Emacs and the Vi family. If I wanted IDE features in my text editor, then I would probably be better served using an IDE. Less to manage is less to burden.
jauntywundrkind 15 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
lcvriend 13 hours 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.
mehalter 12 hours 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...
jauntywundrkind 4 hours ago [-]
Apologies & thanks. AstroNvim used lazy.nvim, which is a (ragingly popular) plugin loader, not LazyVim, a setup for nvim also based on lazy.nvim.
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.
never_inline 11 hours 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.
userbinator 16 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.
bionsystem 11 hours 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 :'(
elektrontamer 16 hours ago [-]
Same. I barely edit default configs. I also mostly use emulators provided by whatever ide I use.
ventana 17 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 15 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.
crehn 8 hours ago [-]
Same. And if I may, that led me to creating a Vim file browser that runs in a separate terminal (tmux pane!) so I have fewer window navigation shortcuts to remember: https://github.com/hoffa/vitree
avadodin 13 hours 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.
ab71e5 9 hours ago [-]
Why cscope and not an LSP?
raimo 17 hours ago [-]
Yes indeed, same here!
be_erik 18 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.
normie3000 16 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 14 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 17 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 17 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.
pmontra 16 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 16 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 13 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.
owl57 13 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.
ethagnawl 14 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.
ghost-of-dmr 5 hours ago [-]
If you were to sweep it under the rug, then it wouldn't be a history lesson, now would it?
Scarbutt 17 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.
NewsaHackO 11 hours 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.
throawayonthe 11 hours ago [-]
you keep using that word, 'apolitical', i do not think it means what you think it means
NewsaHackO 8 hours ago [-]
I only used it once.
helterskelter 16 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 14 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.
grebc 17 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 15 hours ago [-]
Simple tool? Visual text editor is probably the most complicated piece of software in coreutils.
throawayonthe 11 hours ago [-]
there's a visual editor in coreutils? i didn't realize
oh i guess there's GNU Readline, but that's not in coreutils i think
ivanjermakov 10 hours ago [-]
No, you're right. I meant "universally included in Linux distributions".
elxr 13 hours 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 16 hours ago [-]
...and presumably quit vi once you're done!
rmunn 15 hours ago [-]
I have typed either :wq or ZZ into so many files in VS Code... :-)
elxr 13 hours 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.
1vuio0pswjnm7 3 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."
Been using vi for decades, mostly nvi and vim 4.6 since UNIX became available for the PC. I still feel like I only utilise a small fraction of what's possible. I believe I do many things "the slow way". In truth I prefer non-interactive editing, e.g., ed, sed, flex
I once saw a video on YouTube that was a "meme" clip of a presenter doing some text manipulation with vi while sharing his screen at a conference. The clip had had been edited to suggest what he was doing with vi was somehow particularly impressive, e.g., mind-blowing "("mind blown")
Everything he was doing was stuff I do all the time. I thought WTF
aweiher 11 hours ago [-]
I wonder why there never was a vii, viii or ix?
mghackerlady 8 hours ago [-]
Thanks, now I know what to name a new modal editor if I ever make one
loloquwowndueo 11 hours ago [-]
This made my day. Thanks.
openmarkand 8 days ago [-]
I'm vim poweruser since around 2009. When I use VSCodium (not that much today) I obviously use Vim emulation.
When I use a different editor, there will be lots of jjkk or ,w (I nmap ,w to :w). Habits die hard.
Now I switched to neovim due to the amount of good features I like with it. I use exclusively mini.nvim modules that are awesome.
jvillasante 10 hours ago [-]
I use Emacs but these days I spend so much time in the terminal that I'm seriously thinking going back to (N)Vim + Tmux combo. Emacs just feels so slow and complex when you are SSHing into multiple servers while running multiple AIs... I should go read that Vim book everybody recommends!
mghackerlady 8 hours ago [-]
No! Don't go to the darkside, there's alternatives. OpenBSD has mg, which is good enough that it is now the default emacs on macos and is very small
pjmlp 14 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 14 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 13 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 14 hours ago [-]
Agreed.
jasoneckert 7 hours ago [-]
I've used vi (and later vim and neovim) since the 1980s, and really enjoyed reading this site. I had no idea there were so many vi-able alternatives!
nixass 15 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 15 hours ago [-]
And he doesn’t use any config it seems. No syntax highlighting, no line numbers, plain white text on dark background.
some of the openbsd folks use it as a weapon in the fight to prioritize content over presentation. i got a chuckle out of it and it convinced me to stop thoughtlessly hating on comic sans, easy as it is.
weberer 10 hours ago [-]
Its probably the font that helps people with dyslexia.
GuinansEyebrows 30 minutes ago [-]
hmm, not quite OpenDyslexic. looks a little like Comic Mono but maybe a little rounder? the "l" is a lot curvier than most comic-like fonts. almost reminds me of one of the annoying Samsung fonts :)
4ggr0 10 hours ago [-]
ah, good point!
NoSalt 6 hours ago [-]
> "once you learn it, you can be ruthlessly efficient with your editing"
This is no joke. I use it to "massage" data in all sorts of files (.json, .xml, .csv, .txt, etc.), with thousands to millions of lines, in no time at all.
classichasclass 17 hours ago [-]
Long ago I wrote my own really incomplete vi subset for the C64 that I really should dust off. But there's a more polished vi clone for 6502 machines, including the C64, Apple II and Atari: https://vi65.sourceforge.net/
taejavu 17 hours ago [-]
How does an article like this not mention Bill Joy??
ethagnawl 15 hours ago [-]
Bram is a glaring omission in the vi family tree, too. Though, they'd have to draw the line somewhere (i.e. include nvim creator?) and maybe it's better leave individual people out.
dredmorbius 8 hours ago [-]
The article focuses on the variants, not their authors. Joy, Bram, Perens (Busybox) are all omitted. At least the exclusion is nonbiased.
mechanicum 14 hours ago [-]
I think describing Kakoune/Helix as vi-inspired with “slightly different keybindings” is rather missing the point.
The most important difference is that they invert the editing model from verb-noun to noun-verb. Meaning you always see exactly what you’re going to be operating on before you do it.
The second most important difference is that they were designed from the ground up around multi-selection editing as a primitive, rather than a plugin or late addition.
That model is typically less efficient purely in terms of keystrokes, for some operations significantly so, but it’s somewhat mitigated if having the state on-screen rather than in your head means you undo less often.
I wouldn’t suggest either approach is superior. I suspect most people (“most people” in the subset of people who jibe with modal editing to begin with, anyway) will find that one just fits their brain better than the other.
Personally, even having used Vim almost daily since finding it on a Fish Disk sometime in the mid-90s, I still turned out to be in the kak/hx group. I can still use vi quite comfortably when I need to, but Helix removed a bit of friction I’d barely been aware of.
There’s a steady stream of NeoVim exiles to Helix forums, I think who mostly found its Lua-based config too complex/brittle, asking why the devs don’t add settings to make it work like Vim, include a *Vim keymap as standard, etc.
It’s kind of wild to me that people would choose their editor based on how minimalist its config/how batteries-included it is, rather than its fundamental editing paradigm.
keithnz 16 hours ago [-]
I had a mini holiday job working for (long since gone from NZ) Philips Design and Development Laboratory in 1992. As part of that I worked on some tools for their silicon graphics workstations. I was shown vi, and how to get help and left to it. Tough learning curve! Seemed ridiculous at first, then I developed a mini set of editing skills and got used to it! Still using Vim/Nvim today.
Gualdrapo 14 hours ago [-]
vis is absolutely great. Wish more people were aware of it (and it's cool it is mentioned in the post) and that more people used it. I still miss some features from vim, like buffers, but feels so much snappier, lighter and intuitive - and the structural regular expressions part is outstanding.
rfmoz 12 hours ago [-]
Totally agree, Vis really hits an spot between modern feel without losing what made vi great. The structural regex is a game-changer.
mghackerlady 8 hours ago [-]
have you tried sam? or plan 9 in general? I'd recommend both if you haven't (though, plan 9 defaults to acme iirc)
sys_64738 9 hours ago [-]
People in the early days developed enough vi skills to allow them to get by. You could always be sure vi was installed on a remote system you were trying to access in the 90s. You also couldn't install stuff on this system and maybe you were accessing it from an ASCII terminal hooked into the serial port. This typically happened in a data center when you're trying to awkwardly use the terminal due to lack of space. Today I doubt that holds.
rekoros 17 hours ago [-]
When I was in college in 2001, I went to the library and checked out Kaare Christian's book called "The UNIX Operating System". One of the early chapters covered vi - I'd telnet into the school's Sun server with a pretty early version of vi (one-level undo) and follow the examples. Never looked back!
saidnooneever 8 days ago [-]
cool stuff, for a bunch i didnt realise they were really distinct versions!
Use Helix now as the first one that stuck in my fingers though. before that it was always try a lil while and forget it (back to nano...).
Helix i think is like 'user friendly vi' or maybe 'no config vi'. dont need any plugins or weird stuff. everything essential works out of the box (for me)
16bitvoid 16 hours ago [-]
Helix's selection-action feels way more natural to me than vi/vim's action-selection.
opan 15 hours ago [-]
Had someone else parrot this line to me the other day, but I remain unconvinced. Especially when vim has visual mode, and you often can make a select before doing something to it. v$ to select from cursor to end of line, then d to cut or y to copy. Is that not the sort of thing you mean? Is visual mode in vim just underused?
Recently I was trying to find a good way to delete from the current position backward to another character, like dT or dF followed by the target character. The trouble was they'd leave at least one character behind, either what I jumped to or what I started on. What worked how I want, and was still easy, was just using visual mode. Where "n" was the character to jump back to, I did vFn which selected from my cursor position back to the letter n (and including that n). I could then hit d and delete all of it, no extra character left behind from either end. I remember at first I was thinking "there's gotta be a way to do this without visual mode". Best I could come up with was hitting x after dFn or whatever to get the stray character. I think using visual mode is probably fine, though. Maybe if I were doing this type of edit a lot I could bind some key sequence to do it.
Would it be accurate to say you didn't use visual mode much in vim before you moved to Helix?
16bitvoid 12 hours ago [-]
I use visual mode all the time in both vim and helix. Again, the overall selection-action feels more natural for me and doesn't require a separate mode for basic editing, nor do I want to have to switch back and forth from action-selection and selection-action. Also, visual mode is just not equivalent.
For example, I can move forward by word with 'w' and when I get to the word I want to delete, just hit 'd', or edit it at the beginning with 'i' or end with 'a', or surround with parentheses with 'ms('.
I don't want to have to go into a completely separate mode. It's annoying and I have to constantly be cognizant that I need to switch to that mode just to do basic text editing.
> Had someone else parrot this line to me the other day, but I remain unconvinced.
Side note: this comes off as condescending, as if I need to convince you of the validity of my subjective experience. So, along the same lines: I'm unconvinced there is any good argument for vim's action-selection way of doing things when practically no other UI works like that. It's like hitting ctrl+c before highlighting the text you want to copy with your mouse.
rmunn 15 hours ago [-]
Something rather similar to visual mode, and which I've learned to like a lot, is the https://github.com/folke/flash.nvim plugin (NeoVim only since it uses Lua). It gives you a commmand you can bind to a key (https://www.lazyvim.org/ defaults to binding it to `s` for "Seek"). Press that key and then type a couple letters that appear somewhere on your screen. All occurrences of the letters you typed will be highlighted (and the rest will be dimmed), and next to each of them will appear a bright, contrasting letter that serves as a label. Type the label character and you will jump to the start position of the text you typed.
Why is that handy? Well, the idea is that you're probably already looking at the point on the screen you want to move the cursor to, so instead of figuring out a complex navigation, you can type a few keys: `s` plus the letters you're looking at. Then pause for a quarter-second, and type the letter that just appeared where you're looking at. The label letters will be chosen such that none of them appear after the text you typed, e.g. if the words "car", "cat", and "can" all appear in your document, then after you press `sca` the labels `r`, `t`, and `n` will never be chosen. (But the label `d` might be chosen if the word "cad", or words containing it such as "academic", never appear in the document).
It took a little getting used to, but now I've found it's quite the fastest way to issue commands. Want to delete everything from here to that closing parenthesis right there? If you're on its matching open parenthesis then `d%` is fastest, but if you're not, then `ds)` followed by split-second pause to see the label appear (in a bright contrasting color), then type the label. Quite a bit faster than `v` plus a bunch of movement, in my experience. Once you get used to it, it really speeds you up.
And when you get down to it, isn't "once you get used to it, it really speeds you up" a description of the entire vi family of editors in the first place?
rbits 15 hours ago [-]
Well that's one extra key press for every action. For example, you have to do `ved` to delete the current word instead of `de`. Whereas in Helix it's just `ed`.
Also visual mode doesn't work the same. If I want to delete up to the next word normally I do `dw`, but if I do `vwd` then I also delete the first letter of the next word. I guess in visual mode you'd have to do `vwhd` or `vawd`? Which is 4 keypresses instead of 2, which isn't great for something that I do all the time.
rmunn 15 hours ago [-]
I think you're right and visual mode is underused. It gives you the best of both worlds: "cw" meaning "change word" for when it's obvious what you're going to be selecting, and "v3wwwc" for "change 5 words" when you discover (by experimentation) that the text you wanted to change actually counted as 5 words due to punctuation, not 3 as you had first thought.
rbits 15 hours ago [-]
I really want to use Helix, it clicks with me so much more. But I do not want to learn how to use Helix for development. I want to be able to continue using VSCode. And last I checked, the VSCode extension was not very good. I also use Vim keybindings in Obsidian.
The moment VSCode and Obsidian support improves, I am switching immediately.
16bitvoid 11 hours ago [-]
I switched from VSCode to Zed, which has a helix mode built-in and it works very well. For Obsidian, I use markdown-oxide with helix and just use the Obsidian app as a viewer. A helix-mode for Obsidian would be sooo nice.
elch 13 hours ago [-]
Debian is using this upstream repository for nvi and UTF-8 is supported.
The first work i had to use vi and screen on a terminal, it were in 90s . I was used to dos editors ( edit, turbo C ... ) and windows . It was a pain. copy and paste at first was a nightmare. Copy from one file to another ,with named register and # was an hell ( it was vi not vim so only 2 files a time ,the actual edited and the prior ones ). I hated that place, that work, those tool for a while . I got so used to vi, to modify columns with regular expression or macro that now, more than 30 years after , vi/vim is the first thing I install on a PC and when i have to modify a file, or to do something complex, the first and last resort for doing it without python or perl, is always vi . But the beginning at 25 years old was very hard because it was a kind of editing even at those time completely out of my usual way to work . Now it is the only editor that i open and use without thinking . VSCode is great, tons of features, but when i see all those menu, if i can, i use vi . I would add a point. for a while i went behind vim features, try to learn them and use them but they are too many and i often work on different machine so i can not move my setup everywhere. Learning the "old vi way" of doing things (motion, regexp,registers, macros ) can seem "limiting", but at the end you can do quite everything with the same tool .
_torsk_ 13 hours ago [-]
I actually learned VI using DOS and the Watcom C/C++ compiler and 32 bit dos extender, as it included a vi clone.
I think use of the Watcom compiler led me to Vi way back then, and I am still trying to learn to not use the arrow keys.
gpvos 11 hours ago [-]
This should definitely be included! Never heard of it before.
tmtvl 12 hours 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.
One of these days™ I want to add syntax highlighting to nvi/openbsd vi. Maybe remove the perl scripting (I don't like perl, but I do like tcl, much to RMSs dismay)
arethuza 13 hours ago [-]
I learned vi in '86 or so mid way through the CS course I did. Later on I used emacs and various other editors for many years. The weird thing is that the basic vi commands are hardwired in my brain - I could happily edit a file in vi but I'd be stuck if I had to use emacs (even though I actually used emacs for far longer)...
Pay08 13 hours ago [-]
Interesting. Besides the navigation commands and the most basic of shortcuts, I've never been able to learn vi keybindings, even when I was actively trying. Half the time I still can't remember whether j or k is up.
kouosi 15 hours ago [-]
Hi you may want to include neatvi[0] and nextvi[1].
I first used ed(1) back in the ye olden days of early 1980s, vi was like a major advance.
Came in handy when I had to talk a guy through updating a Solaris config file to allow the box to boot when he only had a serial console in the early 2000s.
mghackerlady 8 hours ago [-]
ed is good. If, for whatever reason, I was forced to only use line mode editors for the rest of time, you can't do much better than ed (besides ex, I suppose)
rax0m 14 hours ago [-]
Interesting that there is such a clearly stated differentiation between projects that use "LLM-generated code" and those who don't.
I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
thih9 14 hours ago [-]
Early tractors were attempted in 1800s but most farmers ignored them as they were complex, expensive and occasionally exploded[1].
Sounds familiar.
[1]: “However, even though steam-powered tractors provided an alternative to draft animals, the size, mechanical complexity and risk of explosion rendered these tractors unusable for most farms.” https://www.volocars.com/blog/history-of-tractors-in-agricul...
yrds96 6 hours ago [-]
The LLM usage are disclosed only for the projects where this information is relevant.
By the way there are a lot of farmers that doesn't need the power of tractors to make farming their livehood. Makes sense when you realize that not everything needs to be super fast and efficient, sometimes cheap, slow and constant is enough.
ArcHound 14 hours ago [-]
Pretty well if you consider the "bio" label, which is a set of practices not using all of the tech. They can ask for and usually get higher prices for the products.
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
keyle 15 hours ago [-]
I didn't know about vim-classic, I've switched to it now. I can't really notice much of a difference except themes are missing... and fzf needed a fix.
casey2 18 hours ago [-]
Sam isn't graphical there is sam and samterm which sends commands to sam. sam itself is an ed style line editor, where the concept of a line is replaced with a dot. vis allows multiple dots.
It's worth noting that a lot of the text editing done in the vi family are just calls to ed with different ways of doing selections.
salvesefu 2 hours ago [-]
"Sam is designed as two synchronous programs: a command interpreter and a mouse-oriented bitmap windowing interface."
I wonder if people who stuck with vi(m) know about Xerox PARC, wysiwyg, gui and nomodes.
yu3zhou4 14 hours ago [-]
There was onivim that was a bit hyped a few years ago but unfortunately it died
vladde 10 hours ago [-]
small fun fact: "vi" means "we" in Swedish
"The we family" :)
yrds96 6 hours ago [-]
In Portuguese "vi" means "saw" (past of see) and vim means "came", the last one being source of many inside jokes in one of my first jobs
strenholme 13 hours ago [-]
This list is very useful; Vile isn’t quite Vi, but it’s close enough, and it includes a Windows32 binary which works with CP-1252 [1] (albeit in a separate window), and fits in under 700k (7-zip compressed).
What I wish existed was a fork of Busybox Vi which fully supports UTF-8. I’ve looked at the code and it would require a considerable rewrite to make it UTF-8 compatible, so I can see why it hasn’t been done.
> Nvi 2 (nvi under openbsd) has Unicode support. It's like BSD Vi but with Iconv. Perfect for my needs.
My primary editor for text (not code) editing and e-mail. I just wish Unicode support made it into base vi(1) on OpenBSD, but for now I can at least use it for all other purposes other than the ones in the previous sentence.
anthk 7 hours ago [-]
Ironically ed(1) supports Unicode under X if you XTerm and locale are set for that.
selectedambient 9 hours ago [-]
i can't :q you vim
mghackerlady 8 hours ago [-]
E37: No write since last change (add ! to override)
jgalt212 11 hours ago [-]
> wondering why so many people would choose to use a fifty year old text editor with a notoriously steep initial learning curve
The alternative is just as steep, if not steeper.
crabbone 13 hours ago [-]
If the author is reading this: would be nice to have a "family tree" diagram.
DeathArrow 17 hours ago [-]
I have nothing against Vi or Emacs, but since I strongly prefer GUI and mouse over terminal I use GUI editors.
When I don't have a GUI available, I use micro, nano, joe.
opan 15 hours ago [-]
I'm more in the vim camp, but I will say emacs has one of the best GUIs out there. Everything that works in the terminal still works (great keyboard accessibility), plus you get additional benefits, like proper window separation that isn't just a text character drawing an imaginary line (so copying lines of text with the mouse when you have a bunch of splits is easier). There's also image support, you can connect to a server with TRAMP, open up dired, and view remote images right in emacs. I always thought that was cool.
Vim on the other hand never felt like it benefited much from a GUI, or like it had a very good one available. I just use neovim in a terminal.
tmtvl 12 hours ago [-]
I expect the vast majority of Emacs users to use the GUI rather than the TUI. In fact, the way I learned Emacs was by clicking on 'Help' in the menu bar and then on 'Emacs Tutorial'.
berkes 14 hours ago [-]
With vim/nvim/gvim etc, you can use both.
Granted, the UI is still TUI, so items like panes, tabs, nerdtree, quickfix, :help windows etc are rendered with characters, but you can drag borders, mouse-select text, click files, focus panes by clicking, scroll-wheel, etc.
mghackerlady 8 hours ago [-]
Maybe try emacs if you haven't. It is primarily a GUI editor
pjio 16 hours ago [-]
Being able to choose is a good thing. Use what works for you. I prefer the terminal, but not as hard core as switching to a TTY and never see a GUI again...
mr_toad 4 hours ago [-]
> Being able to choose is a good thing. Use what works for you.
If you look at many of the ‘user stories’ in this thread (and others), you see a lot of people using vi/vim not because they decided to try it, but because they had no real choice. Very often it’s the only usable option on a Unix-like machine.
And yet, you don’t see many people bemoaning the choice. Despite being forced to use it, once people are over the fabled learning curve they tend to like it.
karel-3d 15 hours ago [-]
honestly only LLMs can write Vimscript
yanis_t 16 hours ago [-]
It’s funny how many forks aiming to keep it free from LLM-generated code. The luddites are present even in the most progressive parts of the population.
aiscoming 16 hours ago [-]
vi was never progressive, it was "the Ancients knew it better, the present sucks, these kids have terrible taste, return to the one true Past"
nananana9 14 hours ago [-]
The Ancients did know it better.
I sometimes try working without vim keybindings as it's a pain installing them everywhere. I usually give up the 3rd time I have to delete a function argument and can't dt, or select the body of a function and can't vi{.
For everyone even somewhat decent at vim, having to hold right arrow until the cursor reaches the target is a humiliation ritual, and I genuinely feel second-hand embarrassment and pity when I see people do that.
aiscoming 14 hours ago [-]
allow me to quote the Ancients, the vi creator himself:
> What would you do differently?
> JOY: I wish we hadn't used all the keys on the keyboard.
> ...
> JOY: 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.
> Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.
shots fired:
> JOY: I can just look at my screen, and when I print it off, it's the same as it looks on the screen. It is formatted, and I'm tired of using vi. I get really bored. There have been many nights when I've fallen asleep at the keyboard trying to make a release. At least now I can fall asleep with a mouse in my hand. I use the Xerox optica mouse instead of the other one because it is color coordinated with my office. Did you notice? I prefer the white mouse to the black mouse. You've got to have some fun, right?
That's why it's so complicated, and has left and right parentheses commands. You start out with a clean concept and then sort of accrete guano. It lands on you and sticks and you can't do anything about it really.
But of course he was wrong about 1991-2026:
The days of non-raster stuff are numbered, though sheer momentum will carry it to the end of the decade.
And about AT&T as the same year (1984) they introduced BLIT terminal:
The fundamental tension in UNIX that I think AT&T doesn't understand is that everyone is going to have a bitmap.
> The fundamental problem with vi is that it doesn't have a mouse
The fundamental advantage of vi is that it doesn't have a mouse. If you were born with three arms you can go for sam or something.
mghackerlady 8 hours ago [-]
I think one of those early thinkpad keyboards is ideal. You can use the mouse without leaving home row. I wish there was a nice mechanical keyboard with a thinkpad nipple
flaunf221 12 hours ago [-]
The Ancients used HJKL instead of JKL: - which is where fingers rest with proper touch typing - simply because the ancients had keyboard with arrows drawn at HJKL.
It's a copy-paste design.
skydhash 11 hours ago [-]
My pinkies are not that strong to have to rely on the right one for navigation. I usually move my whole hand to press with the pinkies.
yanis_t 10 hours ago [-]
Well, I use Vi (NeoVim) and love it. In fact I use it with language servers and Copilot (LLM) and couldn't be happier. You can't get any more modern than that.
kps 8 hours ago [-]
vi sure was progressive; it added a full 2D video terminal mode to ex, which was an extension of ed, which was based on Thompson's addition of regular expressions to QED.
remix2000 10 hours ago [-]
Luddites didn't protest against automation, but rather against inhumane working conditions in factories and smashing their machines just happened to be efficient at destroying profit. So in a way, you could say luddites acknowledge technology for what it is, it's just techbros who fail to comprehend basic facts about machine learning and pushing text compression models as a replacement for everything they (don't) know anything about.
keybored 13 hours ago [-]
I think you are wrong. Luddites don’t seem to exist any more, at least not on this board. Luddites had the courage to smash machines. People on this board might have complaints about LLM but then they will say well what can I do, protesting these developments is not on the Story Board.
I’ve never used it because I thought it would make me some lightning fast super developer. I’ve always used it because it’s simply fun. It’s makes editing into this interesting sort of game. You start out with a simple set of skills from vimtutor, and inevitably brute force your cursor around the screen for a while. Little by little your movements become more complex and efficient, and the journey to figuring that out is fun and interesting.
It makes you think about typing in a totally different way. It makes it into a some kind of interesting game where your goal is to accomplish a task in the fewest keystrokes possible. That problem solving aspect scratches an itch inside my brain that has always kept me coming back. It’s just fun, and I don’t think that gets talked about enough
The added benefit I found is that Vim’s purely keyboard based design is much, much easier on the wrists. Heck, I pushed myself to learn Vim because I started to feel wrist pain due to KB and mouse switching.
Macros, dude.
It's a bit annoying to become disciplined in text structure/regularity to have macros work flawlessly, but it's a bliss afterwards.
And then... recursive macros.
(I know Emacs has better macros but vim macros are way easier and fun for everyday use).
vi definitely doesn't scratch that "itch" for everyone in the same way. But for me, it's as though I found a cheat code. Getting better at vi feels like getting better at a game - only practicing this game makes you better at any number of tasks that are relevant to your daily work.
(although if you also want to get better at typing speed, there are surprisingly fun roguelikes on Steam for just this purpose)
Vi key bindings don't apply outside of vi
The shells themselves also support vi binding.
Outside of the terminal tools like Vimium add support to browsers and many other interfaces.
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.
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.
I never made that switch. The muscle memory of 2 decades of using a software is under appreciated.
For me, it is about preference for what to optimize for.
I love CLI tools that effectively give me the things an IDE would offer such as astgrep for refactoring for example. zoekt with a browser does pretty good indexed searches. fzf can be used to build up almost any useful way of selecting things that you can imagine. So the CLI becomes my IDE.
Hence, I will stick to my piano.
> 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".
Bill Joy, the original author of vi, saw the vi commands as a problem, not a solution [1]:
[1]: https://web.archive.org/web/20120210184000/http://web.cecs.p...:set mouse-=a
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.
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.
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.
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`
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.
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
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.
Ref on lazy.vim: https://docs.astronvim.com/configuration/customizing_plugins...
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.
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 :'(
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.
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.
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.
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.
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.
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.
As an extreme example, today I needed to combine parts of two files into one and decided that
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.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.
Seems like an interesting fact for those who don't follow the development of vim/neovim.
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.
oh i guess there's GNU Readline, but that's not in coreutils i think
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.
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.
Been using vi for decades, mostly nvi and vim 4.6 since UNIX became available for the PC. I still feel like I only utilise a small fraction of what's possible. I believe I do many things "the slow way". In truth I prefer non-interactive editing, e.g., ed, sed, flex
I once saw a video on YouTube that was a "meme" clip of a presenter doing some text manipulation with vi while sharing his screen at a conference. The clip had had been edited to suggest what he was doing with vi was somehow particularly impressive, e.g., mind-blowing "("mind blown")
Everything he was doing was stuff I do all the time. I thought WTF
When I use a different editor, there will be lots of jjkk or ,w (I nmap ,w to :w). Habits die hard.
Now I switched to neovim due to the amount of good features I like with it. I use exclusively mini.nvim modules that are awesome.
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.
If anyone wants to have a look: https://www.youtube.com/watch?v=IXBC85SGC0Q
Correction, the driver is specifically for Apple Xserve front-panel
some of the openbsd folks use it as a weapon in the fight to prioritize content over presentation. i got a chuckle out of it and it convinced me to stop thoughtlessly hating on comic sans, easy as it is.
This is no joke. I use it to "massage" data in all sorts of files (.json, .xml, .csv, .txt, etc.), with thousands to millions of lines, in no time at all.
The most important difference is that they invert the editing model from verb-noun to noun-verb. Meaning you always see exactly what you’re going to be operating on before you do it.
The second most important difference is that they were designed from the ground up around multi-selection editing as a primitive, rather than a plugin or late addition.
That model is typically less efficient purely in terms of keystrokes, for some operations significantly so, but it’s somewhat mitigated if having the state on-screen rather than in your head means you undo less often.
I wouldn’t suggest either approach is superior. I suspect most people (“most people” in the subset of people who jibe with modal editing to begin with, anyway) will find that one just fits their brain better than the other.
Personally, even having used Vim almost daily since finding it on a Fish Disk sometime in the mid-90s, I still turned out to be in the kak/hx group. I can still use vi quite comfortably when I need to, but Helix removed a bit of friction I’d barely been aware of.
There’s a steady stream of NeoVim exiles to Helix forums, I think who mostly found its Lua-based config too complex/brittle, asking why the devs don’t add settings to make it work like Vim, include a *Vim keymap as standard, etc.
It’s kind of wild to me that people would choose their editor based on how minimalist its config/how batteries-included it is, rather than its fundamental editing paradigm.
Use Helix now as the first one that stuck in my fingers though. before that it was always try a lil while and forget it (back to nano...).
Helix i think is like 'user friendly vi' or maybe 'no config vi'. dont need any plugins or weird stuff. everything essential works out of the box (for me)
Recently I was trying to find a good way to delete from the current position backward to another character, like dT or dF followed by the target character. The trouble was they'd leave at least one character behind, either what I jumped to or what I started on. What worked how I want, and was still easy, was just using visual mode. Where "n" was the character to jump back to, I did vFn which selected from my cursor position back to the letter n (and including that n). I could then hit d and delete all of it, no extra character left behind from either end. I remember at first I was thinking "there's gotta be a way to do this without visual mode". Best I could come up with was hitting x after dFn or whatever to get the stray character. I think using visual mode is probably fine, though. Maybe if I were doing this type of edit a lot I could bind some key sequence to do it.
Would it be accurate to say you didn't use visual mode much in vim before you moved to Helix?
For example, I can move forward by word with 'w' and when I get to the word I want to delete, just hit 'd', or edit it at the beginning with 'i' or end with 'a', or surround with parentheses with 'ms('.
I don't want to have to go into a completely separate mode. It's annoying and I have to constantly be cognizant that I need to switch to that mode just to do basic text editing.
> Had someone else parrot this line to me the other day, but I remain unconvinced.
Side note: this comes off as condescending, as if I need to convince you of the validity of my subjective experience. So, along the same lines: I'm unconvinced there is any good argument for vim's action-selection way of doing things when practically no other UI works like that. It's like hitting ctrl+c before highlighting the text you want to copy with your mouse.
Why is that handy? Well, the idea is that you're probably already looking at the point on the screen you want to move the cursor to, so instead of figuring out a complex navigation, you can type a few keys: `s` plus the letters you're looking at. Then pause for a quarter-second, and type the letter that just appeared where you're looking at. The label letters will be chosen such that none of them appear after the text you typed, e.g. if the words "car", "cat", and "can" all appear in your document, then after you press `sca` the labels `r`, `t`, and `n` will never be chosen. (But the label `d` might be chosen if the word "cad", or words containing it such as "academic", never appear in the document).
It took a little getting used to, but now I've found it's quite the fastest way to issue commands. Want to delete everything from here to that closing parenthesis right there? If you're on its matching open parenthesis then `d%` is fastest, but if you're not, then `ds)` followed by split-second pause to see the label appear (in a bright contrasting color), then type the label. Quite a bit faster than `v` plus a bunch of movement, in my experience. Once you get used to it, it really speeds you up.
And when you get down to it, isn't "once you get used to it, it really speeds you up" a description of the entire vi family of editors in the first place?
Also visual mode doesn't work the same. If I want to delete up to the next word normally I do `dw`, but if I do `vwd` then I also delete the first letter of the next word. I guess in visual mode you'd have to do `vwhd` or `vawd`? Which is 4 keypresses instead of 2, which isn't great for something that I do all the time.
The moment VSCode and Obsidian support improves, I am switching immediately.
https://repo.or.cz/nvi.git
Maybe it should be included in the list. It can still be downloaded from the openwatcom project, https://openwatcom.org/ftp/manuals/1.5/vi.pdf
I think use of the Watcom compiler led me to Vi way back then, and I am still trying to learn to not use the arrow keys.
https://youtu.be/9n1dtmzqnCU?t=71s
[0]: https://github.com/aligrudi/neatvi
[1]: https://github.com/kyx0r/nextvi
Came in handy when I had to talk a guy through updating a Solaris config file to allow the box to boot when he only had a serial console in the early 2000s.
I wonder how it went for the farms that stuck to "non-tractor-generated crops" in the 1900s.
Sounds familiar.
[1]: “However, even though steam-powered tractors provided an alternative to draft animals, the size, mechanical complexity and risk of explosion rendered these tractors unusable for most farms.” https://www.volocars.com/blog/history-of-tractors-in-agricul...
By the way there are a lot of farmers that doesn't need the power of tractors to make farming their livehood. Makes sense when you realize that not everything needs to be super fast and efficient, sometimes cheap, slow and constant is enough.
Granted, it's more about chemicals than tractors, but still quite close to the spirit of the comments. Bio approach sacrifices some tech advances.
It's worth noting that a lot of the text editing done in the vi family are just calls to ed with different ways of doing selections.
https://en.wikipedia.org/wiki/Sam_(text_editor)
"The we family" :)
What I wish existed was a fork of Busybox Vi which fully supports UTF-8. I’ve looked at the code and it would require a considerable rewrite to make it UTF-8 compatible, so I can see why it hasn’t been done.
[1] https://en.wikipedia.org/wiki/Windows-1252
On graphical Vis, I liked Cream, which almost made Vim seamless.
https://cream.sourceforge.net/
Instead of GTK2/3, I prefer Athena Vim.
My primary editor for text (not code) editing and e-mail. I just wish Unicode support made it into base vi(1) on OpenBSD, but for now I can at least use it for all other purposes other than the ones in the previous sentence.
The alternative is just as steep, if not steeper.
When I don't have a GUI available, I use micro, nano, joe.
Vim on the other hand never felt like it benefited much from a GUI, or like it had a very good one available. I just use neovim in a terminal.
Granted, the UI is still TUI, so items like panes, tabs, nerdtree, quickfix, :help windows etc are rendered with characters, but you can drag borders, mouse-select text, click files, focus panes by clicking, scroll-wheel, etc.
If you look at many of the ‘user stories’ in this thread (and others), you see a lot of people using vi/vim not because they decided to try it, but because they had no real choice. Very often it’s the only usable option on a Unix-like machine.
And yet, you don’t see many people bemoaning the choice. Despite being forced to use it, once people are over the fabled learning curve they tend to like it.
I sometimes try working without vim keybindings as it's a pain installing them everywhere. I usually give up the 3rd time I have to delete a function argument and can't dt, or select the body of a function and can't vi{.
For everyone even somewhat decent at vim, having to hold right arrow until the cursor reaches the target is a humiliation ritual, and I genuinely feel second-hand embarrassment and pity when I see people do that.
> What would you do differently?
> JOY: I wish we hadn't used all the keys on the keyboard.
> ...
> JOY: 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.
> Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.
shots fired:
> JOY: I can just look at my screen, and when I print it off, it's the same as it looks on the screen. It is formatted, and I'm tired of using vi. I get really bored. There have been many nights when I've fallen asleep at the keyboard trying to make a release. At least now I can fall asleep with a mouse in my hand. I use the Xerox optica mouse instead of the other one because it is color coordinated with my office. Did you notice? I prefer the white mouse to the black mouse. You've got to have some fun, right?
http://xahlee.info/comp/interview_with_bill_joy.html
But of course he was wrong about 1991-2026:
The days of non-raster stuff are numbered, though sheer momentum will carry it to the end of the decade.
And about AT&T as the same year (1984) they introduced BLIT terminal:
The fundamental tension in UNIX that I think AT&T doesn't understand is that everyone is going to have a bitmap.
https://youtu.be/Pr1XXvSaVUQ
The fundamental advantage of vi is that it doesn't have a mouse. If you were born with three arms you can go for sam or something.
Of course this is a total digression.