Hacker News new | past | comments | ask | show | jobs | submit login
How Did Vim Become So Popular? (pragmaticpineapple.com)
367 points by nikolalsvk 5 days ago | hide | past | favorite | 495 comments

Speaking personally, I've been a professional developer for almost decade and even in my relatively short career I've seen a lot of technologies come and go. I was reluctantly roped into it by my first boss, an enthusiastic Vim advocate. And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective. From the default mac OS installation to some old Fedora box that has not been patched since the early 2000s, Vim (or its simpler brother Vi) has always been there!

And once I got used to it, I couldn't really imagine using computers any other way. I'd go so far as to say that the 'home row' concept of vim is the ergonomic ideal of keyboard based computing, and I now try to mimic that behavior everywhere -- the vimium extension in chrome, various vim plugins for vs code and sublime etc. If you're on the fence, I'd urge you to give in!

Definitely, even now as I use emacs, I'm a 100% evil. It's just so natural (once you get it), that I don't know how other bindings (like ctrl-[whatever]) are prevalent in most other software, it's not like they are more memorable or intuitive.

Fun story: I was into Free/Libre software as a teen, when I learnt how to move around in vi(m) and in my first tech gig (as a sysadmin), I was interviewed by some greybeard who wanted me to do some maintenance and configuration tasks. I knew the basics of command line environments, but I had never setup LDAP, mail or DNS. So anyway he asked me to setup some repository on yum, and well, at least I knew how to do that. When he saw me using vi commands to quickly edit the file, he stopped the interview, arguing that anybody who was fluent on vi, was obviously a seasoned admin and I got the postion. I never had the guts to tell him otherwise.

It's proof enough that you'll figure it out.

Years of interviewing people for my own teams has shown me that understanding your tools (especially to the point of being opinionated about them) is probably the #1 indicator of success.

Indeed. Someone with the fortitude and discipline to get really good at their tools can probably pick up whatever you throw at them.

Its also a good sign that they might be into technology for its own sake, which also doesn't hurt.

Where I work we use a lot of jetbrains IDE's and I've been a massive fan of Intellij, I absolutely love it when I can show someone something that makes their life easier.

Whether it's how to implement an external program properly using all the expansions or how to use bookmarks (how people can use an IDE for years and not find that is a good question).

I've always RTFM of whatever tool I'm using as the first step then I go look at the default keybindings to see what else there is.

The one that blows people away though is the custom exporters you can write for data views, oh you want that result set in a PHP array for a test set, yeah Copy as PHP has you.

Intellij is absurdly powerful without writing custom plugins (which is my next step I guess).

... and Jetbrains IDEs support a plugin called IdeaVIM that provides pretty solid vi/vim emulation.

IdeaVim is the uncanny value of vim for me. It's so close to being actual vim, but every now and then it does something unexpected and it completely throws me off.

I recorded a macro to change shouldBe([true|false]) to shouldBe[True|False](). Pretty simple: qqf(ds(~$a()<esc>q

But the vim-surround plugin emulation doesn't work properly with macros, so it'd get stuck and instead of just doing n@@ , I'd have to do n@@( , i.e pass the seperator I used for the delete surround command.

It doesn't have fold toggling, so z[a|A] doesn't work. The undo behaves weird, you usually have to do it twice UNLESS you've not moved the cursor since doing the last edit.

The git integration isn't as good as vim-fugitive and I constantly find my self reaching for the mouse to do anything git related, whereas in vim I could do it all with the keyboard.

The plugin gets brought up all the time when people talk about the JetBrains tools and no one seems to mention the short comings.

Some people are satisfied with the modal editing paradigm of Vim that they don't need its advanced features.

(intellij sometimes has recurring problems with lost keyboard input under linux+gnome. IdeaVIM is one of the first plugins i disable, when that happens. and it often helps.)

What a great test, and it makes sense - a craftsman cares very much about their tools, an average tech will use the first thing that they're taught.

It's also what's so hard about hiring junior candidates and why so many companies shy away from it.

Truly junior hires don't really know the tools yet. You can't really afford to wait for the rare junior who does, so unfortunately it's not as useful a test in that situation.

That's why I think OP's "seasoned sysadmin" line is perfectly valid. The junior that knows their tools has already cleared the hardest hurdle for most companies. Everything else is trainable through mentorship, but tools usage requires experience.

Indeed, I always advise people who want to be developers to build some stuff to show, to separate yourself from everyone else, and make it easier for the hirer. That is another reason to do it, an IT degree doesn't mean you can write code, as you say the rest can be learnt.

An IT degree is not about writing code. Perhaps you are referring to CS.

You become used to the first tool you pickup, its ways become "natural", and hence you become opinionated.

I don't know about that, my first tool was vi, I have strong opinions about it :-). I use an all singing IDE (Appcode) now, its not perfect either but works for now.

(Funnily enough ctrl-[ is one of my most used shortcuts in vim. It’s a convenient alternative to escape if you map caps-lock to ctrl)

Even better: map held Caps to Ctrl and a tap of Caps to Esc

I map held Caps to Super (so I can switch windows and use other higher-than-application-level shortcuts without leaving the home row in dwm), but yes, definitely don't limit yourself to one use for your keyboard's most convenient key without a use. In X11 it's as easy as

    setxkbmap -option caps:super
    xcape -e 'Super_L=Escape'
(where setxkbmap is built into X, and xcape is a one-command install away). And IIUC you can do this with ~6 clicks in a third-party GUI like https://karabiner-elements.pqrs.org/docs/manual/configuratio... in macOS.

I really don't like chord like shortcuts, while ctrl and [ are positioned in a way you don't have to contort your hand it kind of requires you to move away from the hjkl row or stretch your pinkies. Consider mapping esc to jk (as a sequence) it works surprisingly well.

  inoremap jk <esc> 

  inoremap <esc> <nop>
so that you never use esc again

not having chord like shortcuts was one of the main reasons that led me to try vim over emacs in the beginning, so I kind of think they're "anti" vim.

I've been using ctrl-[ for years, but have been experimenting with jj. Now I'm not sure which one I like better!

I switched back to vim+tmux (nvim) a few weeks ago from a number of years using vs-code with the vim keybindings.

I'm still trying to configure my plugins so that I don't feel like I'm repeating myself too often.

Having ctrl-[ in your muscle memory has the advantage that it also works in other readline programs that have a vi like interfacee, e.g. bash, zsh and many db consoles.

I recommend mapping jk to esc in insert mode (instead of jj), so you remain on the same line if you accidentally use it in normal mode.

Note, don't do this if you're Dutch, words with 'jk', or rather 'ijk' in them are annoyingly common.

This is now my muscle memory escape key since an embarrassingly cheap Bluetooth keyboard of mine only allowed escape == home button on my Android devices.

Pro Tip: Park the flesh of your left palm near the left ctrl key and use that instead of your pinky for ctrl. I admit this feels a bit weird at first but avoids the need to lift your fingers from the home row. Super bonus: use ^H for backspace. Try it out!

Note: Often Ctrl-3 does the same thing.

That's excellent!

That gives a left handed option for escape without leaving the home row. I really like having mirrored shortcuts like that, thank you.

Omg that is such a game changer for me. way more ergonimic than hitting esc

You may be using vim wrong. Good for you if you like it that way

You're going to have to explain that one because I generally switch back to command mode after every edit so I use ctrl-[ a lot.

I'd be VERY interested to hear why that's wrong and what you do differently.

my reasoning was : you could have mapped caps lock to ESC but you did not. So maybe you are using CTRL too much (CTRL-V maybe?) which is not the best way to use vim.

No your reasoning is way off. I map to ctrl rather than escape because I want to make use of the Insert and Ex mode ctrl shortcuts.

For example, if I want to insert a register into the ex mode command line I use ctr-r <register>.

Or if I want to pop out of insert mode for a single command I use ctr-o.

E.g. inserting opening and closing tags when a suitable plugin isn't present. Insert the opening and closing tag, jump back to command mode with ctrl-o, move backwards and you're ready to insert more text.

Can't speak for everyone, but I use this[1] keyboard most of the time, and it doesn't have a Caps Lock key to remap, but instead has Control where Caps Lock normally is. So using ctrl-[ is much easier than reaching up to the escape key.

[1] https://hhkeyboard.us/pro-classic/

Using Ctrl-[ is perfectly fine if that's convenient to you. Some people doe "inoremap jj <esc>" and double tap j to exit insert mode. If it's faster for you than pressing regular escape, it's an improvement, and thus good.

Politely, I'd consider rephrasing this in the future. Not everyone springs forth into the world with a 5kloc .vimrc. Everyone is incrementally learning from someone else at their own pace.

I'll do. Thank you. I did not realise I was mean because english is not my native language

Yeah, I think you got lucky. He sounds like a great boss. And, he was probably right.

Such a thing is a proxy character trade and probably told him enough. I'm in bioinformatics, if an applicant tells me they studied biology but have always run a Linux server at home, I can also stop the interview: hired.

Heh, I would fall for that!

Same here, and then i discovered EVIL, the vi layer for emacs. The best of all worlds: Vim text manipulation grammar over the emacs engine.

I've used Emacs for many years, and recently switched to Spacemacs, a set of configs that kind of takes over Emacs and puts a great platform on top of it.

I frequently describe Spacemacs as a better vim than vim. Don't get me wrong, I've used vim for ages; I'll never stop editing server config with vi, nor will I stop getting mad when vi is actually vi and not vim.

But for a day to day code editor? Spacemacs is astonishingly good.

(Of course, Spacemacs is built on top of EVIL, as well as dozens of other packages. On the shoulders of giants, as we say.)

The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings. And because of that Evil mode has the same limitation, beside its insistence to prefer using builtin Emacs functionality over emulating Vim behaviour correctly.

And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications. I usually like to run Vim in a terminal multiplexer and combine it with various terminal utilities when needed, and Emacs doesn't support that - unless you run it in a terminal, but then Evil mode stops working properly...

I'm fine with Vim, but I'm glad I tried Emacs for a while because it does have some nice ideas.

> The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings.

Interesting, my impression was that custom keybindings was more flexible in Emacs + Evil than in Vim. It seemed easier to e.g. define new modes with separate keybindings, and if you use the GUI version, more distinct keybindings are available.

> And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications.

It can now. The problem is that there are a lot of shells and terminals available in Emacs, so it's not always obvious which one supports what. But emacs-libvterm [1] is a "real" terminal inside Emacs, and supports ncurses apps well. (The website warns about being alpha level, but I used Emacs + Evil for about half a year, and it worked fine for me.)

[1]: https://github.com/akermu/emacs-libvterm

> I'm fine with Vim, but I'm glad I tried Emacs for a while because it does have some nice ideas.

I ended up with the same conclusion :).

I have to agree. Emacs w/ Evil is a nice solution and gets almost there, but there are enough edge cases that interfere with the elegance of pure Vim. Everytime you install a new emacs plugin, you have to consider that it will use Emacs keybindings, not Vim, and you jump through hoops to remedy that, or, more often, you find yourself having to mix the emacs ways and the Vim way, which I personally found annoying after awhile.

Emacs is awesome and more powerful overall, but actually using Vim is easier -- from setting up keybindings, configuring your vimrc file, it's all quite simple compared to what you can do, and often do, in setting up Emacs.

But to be honest they are much closer to each other than either is to a more conventional/modern IDE. They are spiritual siblings for sure.

> The problem with Emacs and all its modifications is that it cannot match Vim's flexible system for custom keybindings. And because of that Evil mode has the same limitation

Can you explain what limitations you mean? What keybindings has vim over emacs?

> And the other thing that I could never get used to is that Emacs' terminals can't handle ncurses applications.

libvterm seems to have solved this problem recently. Works well enough that I can use vim inside emacs.

M-x ansi-term

Wait until you find out about Doom, which I consider to be all the good of Spacemacs without the crust.

Have you taken a look at Doom Emacs? I liked Spacemacs, but I found Doom more performant, as well as not abstracting too much, which allows you to slowly learn Emacs as you go.

Probably in the minority - I have an extensive custom .emacs.d, but I've kept most of the default emacs bindings. Not only do I find them ergonomic (use the side of your palm for ctrl!), they're also the same bindings you'll find in most terminals. Additionally, emacs does so much more than editing, and having consistent bindings across tasks is really convenient (I'm super lazy :).


``` set -o vi ```

problem solved! no more emacs pollution!

Alas, the emacs install base is fraction of vi/vim.

I am also surprised by this. What are you basing it on? For arbitrarily comparable online communities, it looks like emacs.stackexchange.com is twice as active as vi.stackexchange.com

> ...the emacs install base is fraction of vi/vim.

> What are you basing it on? ... it looks like emacs.stackexchange.com is twice as active as vi.stackexchange.com

A couple of things about this. For myself and many others, the reason I started vi in the first place is it's been installed by default on many kinds of machines. On SCO Unix and AIX from my youth, for example, this was the editor you used on a vanilla install of a machine to get things going. So this is part of why the install base is larger.

Another part of why the emacs community is more active is that Vi is just an editor, while emacs is more of a programming language and I daresay nearly an operating system in its own right. Because of the amazing power and flexibility of emacs there's a lot more stuff to discuss for Emacs than Vi.

When I was teaching myself to program, I had a night job in a warehouse. It so happened that the inventory software was on a UNIX server, and we accessed it through a terminal emulator from our windows computer. I discovered one day that I could exit the inventory software and end up with a shell prompt, and that the server had Perl available.

My computer books convinced me that emacs was the better editor, but it wasn’t installed on the server. vi was. So I learned vi and Perl on my lunch breaks.

Emacs is more complex, and Emacs users do more in Emacs than just edit text. (think org-mode, debugger frontends, mail readers, etc.)

Well vi or vim is nearly always installed by default everywhere, but emacs rare is so.

Stack Overflow survey (https://insights.stackoverflow.com/survey/2019#development-e...) has Vim at ~25% while Emacs is at 4.5%.

it also has notepad++ at 30.5% - I've seen one or two people who would use notepad++ when nothing else is available, but I don't think many people have it as their primary IDE.

Also, if you sum up all the JetBrains products (which you can get as IntelliJ Ultimate if you shell out the money), you land in the vicinity of 63% (not vim-related but a neat fact)

Vi users RTFM.

I love emacs, but I taught myself to use vi because I know when I ssh into a remote server there will have a vi.

Emacs has an edit-over-ssh mode that's pretty useful.

You can do that in vim via scp like this:

vim scp://user@myserver[:port]//path/to/file.txt

Yes Tramp mode.

Even if it's a Cisco router and there are no text files other than a note.txt 'Here be dragons'

I've always assumed the opposite with how people say emacs is a nice OS and poor editor... What does Vim over emacs?

It's not a comment on quality or usefulness, and only indirectly its resource consumption (vi/vim consumes less than emacs in its default configuration), it's really about standards.

vi and the ex editor language are part of the POSIX standard and were around early in the history of BSD. See the history here: https://en.m.wikipedia.org/wiki/Vi

For a well worn joke on the subject, "Ed is the standard!": https://www.gnu.org/fun/jokes/ed-msg.en.html

I love Emacs and have been using it for years but whenever I want to make a really quick edit, i.e. writing a git commit I almost always reach for vi because by the time Emacs loaded I would've been done committing with vi, at least with a slower machine.

I know some people run Emacs in daemon mode, but it's not always convenient to do that

This and when I ssh into any machine, I know there will be a vi at the very least

> This and when I ssh into any machine, I know there will be a vi at the very least

You could use emacs for that. Editing over ssh using TRAMP works perfectly in every case I've used it.

1) vim is easier on your hands if you're on a high-latency connection (i.e. usable in a terminal) and/or get tired of chording (i.e. having to press Ctrl along with random keys).

2) I've found vim's plugin systems (Pathogen, Vundle, vim-plug) vastly more intuitive than Emacs' version with package-install and activating one of several repositories (Milk, ELPA, MELPA, whatever) - you install the same plugin regardless of whether you're using Vundle or vim-plug

3) vim and its packages are vastly easier to configure - this is subjective and may be much improved in Doom Emacs/Spacemacs, but in general vim packages have a bunch of global variables that you can set to a number or a string whereas most emacs packages need you to define elisp functions and/or nontrivial data structures, with no sane defaults to fall back on if you want things just to work

It’s composability is Vim’s killer feature.

This post is what got me started on Vim: https://stackoverflow.com/questions/1218390/what-is-your-mos...

this is huge flamewar territory, but this is a bit 'off' question wise - alot of the current state of things is due to historical precedent - some details:

- (original) vi was on most unices from the mid-80s onwards out of the box

- (gnu/lucid) emacs was an additional install (not getting into other emacs flavors - original teco emacs was fairly small i believe).

- original vi just had basic editing and at some point a hardcoded lisp mode, no addons vs gnu emacs which was a programmable editing environment running within a lisp interpreter - remeber in the early days, people built whole custom hardware to be able to run lisp with sufficient complexity (see also: lisp machines, twenex, etc), so using lisp for your editor was in some sense the definition of 'overkill', depending on ones view of what an editor should do

- Also, from late-80s->90s era if you wanted a GUI for your text editor you probably used emacs, and real vi never had a gui option - put another way emacs was the only one of the two linked to gui libraries.

- vim vs vi: most obvious difference (IMHO) feature wise is that vim adds vimscript, which is an interpreted programming language, so now editing modes are extensible, etc (as was the case in emacs before). detail: vim codebase is not based on vi codebase.

since vi was just about everywhere and emacs was a (fairly large) package, you had more general vi knowledge vs emacs 'in the culture' since even an emacs user might need to know vi but not usually the other way around, and so vi (later vim, as linux distros switched their 'default vi' to 'vim') gained more install base by default. Then, people hearing about emacs likely hear the 'vi vs emacs' arguments and never try it since there are now many more choices, they've learned vi, they prefer an IDE, etc (in the old days there was much less choice, main 2 were vi and emacs, and emacs was probably somewhere on your managed LAN somewhere if you wanted to give it a shot)

most of the 'vi vs emacs' arguments are rooted in the real-vi vs fsf-emacs era and are basically obsolete in a modern vim era, since everyone is using gui library vim with vimscript, which basically means the same thing in terms of 'bloat' (both editors contain engines to display text in cli or gui mode and embed a language interpreter). Basically what was once valid internet lore kept getting past down, and the 'minimalism' of vim was confused with being 'minimal' in terms of what people meant in the original vi-vs-emacs discussions. Emacs does contain 'non editor' functions e.g. networking, etc, so the core is probably a bit bigger than the core of vim, but when people are still using these comparisons and talking about 'emacs bloat' while their preferred editor is some electron based thing, we've lost a bit of the point/message..

> vim vs vi: most obvious difference (IMHO) feature wise is that vim adds vimscript IMHO, the most obvious difference is that in vim you can kinda just press "i" and pretend its a normal text editor. You know, the kind anyone coming from another OS would already be familiar with. Try doing this in regular vi, and you'll be cursing and pulling your hair out.

Today, I don't put much stock into anyone expressing an opinion in the "vi vs emacs" wars, because 90% of the people claiming a preference for vi seem to actually be vim users. Using vim is a much more pleasant experience than using good old classic vi.

100% concur with this. I learnt Vim many years ago and I genuinely don't know what I'd do without it. It's always just there when I ssh into a new server. And the JetBrains suite has an awesome vim mode meaning I can use most (but not all) vim shortcuts with an actual IDE. I don't think vim itself works well as an IDE substitute, and wouldn't use it for hardcore web dev for example - but for quickly editing random files there's nothing that comes close.

If one wants to do web dev on vim I strongly recommend neovim setup with coc.nvim. I know some people strongly disagree with transforming vim into and IDE, but this is a really productive setup for creating code (works like a charm for my current React project)

Personally I’ll sometimes use VSCode to browse big files or explore the codebase, but when it comes to editing them neovim with coc, fzf and a language pack is all you need.

FWIW coc.nvim does not require the NeoVim fork, it also works with vanilla Vim 8.

Yep, neovim, coc and fzf has made me really productive in vim lately. After years of vim I was tempted to use VS Code until I found out about coc.

>>I don't think vim itself works well as an IDE substitute, and wouldn't use it for hardcore web dev for example - but for quickly editing random files there's nothing that comes close.

Exactly my thoughts, you need vim and emacs these days if you want to munge through large amounts of text. The thing is in these days of Kibana and Elastic search. You don't do much of this kind of work anymore.

Code is text. But it's not that kind of text where you need your fingers and macros to do much work. Your tool needs to be at least to some extent aware and intelligent of code you are working with, or you end up doing too much work for nothing. If your language doesn't have this kind of tooling and you wish to maintain your application for long, you need to use a better commonly used language.

Much of the vim macro work I could put to use is done by black these days. If you are writing too much repeated code, you need to learn to write reusable code. Navigation is one more of those things which could improve if you use intellisense.

Bulk of modern day dev work requires working with 2 - 3 tech stacks. The use case for vim, which is writing few key stroke in one attempt to transmit them over super slow internet connections, doesn't exist anymore.

I'll argue that the IDE is Unix, not vim, I recently started and endeavour to vanilla Vim and I was baffled by what is possible even without plugins, granted I mostly work with C and a bit of Python, but one thing to consider is that most people using Vim come from an IDE background, so horse for course I guess.


Edit: Link

IDE has syntactic understanding of your code, which allows you to navigate your whole codebase as if it's one big hypertext document (invalueable especially when learning new code). Also, the syntactic understanding allows you to do one-click fairly complex refactorings with guarantees that nothing will get broken (at least it works for sane languages, like Java. I don't know how well it works for C/C++, where preprocessor macros complicate things). I don't see how "UNIX as an IDE" delivers this.

Yeah, UNIX doesn't do that on its own. You can grep, or run find and do a bash loop and so on, which is cool. But it's language servers that give semantic understanding of your code. You can easily refactor, or go to definition from vim. So UNIX is a development environment, very flexible, yes, just not that integrated.

I have mainly used vim for development and I can navigate my codebase just as seamlessly with ctags-generated indexes.

I'd agree on vim being of limited utility when it comes to automated refactoring (it's a text editor after all), but beyond changing the names or extracting functions what can an IDE do for you in this respect?

Refactoring in IDEA also allow you to for example also change function signature, safely delete an element (class, function etc.) - i.e. with full impact analysis, move code, extract interface/trait out of a class.

I've tried the ctags-indexes with Sublime and afair the basic navigation was not bad (I think I remember there being an issue with some delay though? It was a while ago). I'm not sure if things like "show code which access this variable" or "show all children of this class" are supported though?

Apart from those advantanges, I can think of two more:

1. IDE can import your build file (maven, sbt or bazel project for example), parse out the project structure from it and download the necessary dependencies. I don't think that ctags-like powered solution is as robust, which means you'd have to fiddle with it until it can understand the structure a complex repo.

2. IDE can run and show the results of unit tests. (just right-click on test you want and select "Run" from context menu).

My build tool spat out a 700MB compile_commands.json file, which the C++ language server turned into 25k files. None of the language server implementations were able to process even a go to file on the code.

it takes about 15 minutes for Visual Studio (well, visual assist) to generate the index for the project, and then the navigation is instant. I've tried a few times over the last few years with various language server and clients, and my experience has been the same pretty much every time.

You can use ctags/cscope to handle that, FWIW languages like C and C++ have a massive toolset built around Vim, so even for the most obscure use case, I'm pretty sure there will be a way.

> at least it works for sane languages, like Java.

You lost me here.

> I don't see how "UNIX as an IDE" delivers this.

Have you read the linked series of articles? The author explains and provide examples with C and Perl, Iirc there's a book about working with Makefiles in Java, so it's totally doable, painful, but doable.

Unix is not an IDE. The I stands for integrated. Unix is just a good old development environment...

Fair enough

The use case of vim is not using an insane amount amount of arrows/ctrl/shift for everything.

It's like a mechanic using just one adjustable spanner and one screwdriver to e.g. replace a clutch. It's ok if you really don't have anything else, but any good mechanic will use a set of good tools. (sorry in advance for the car analogy).

BTW a modern vim setup with CoC is not very short of an IDE, but at lightspeed.

I’m always interested in this opinion.

What IDE features do you think vim is missing that aren’t available via LSP plugins?

I tried getting vim to match my favorite features in VSCode / Jetbrains IDEs and almost went crazy. Rather simple things like code completion or syntax highlighting were already moderately complex to set up. The command palette present in both Jetbrains and VSCode also has thousands of actions easily searchable in plain language, the most simple of which can be replicated with vim (ex: open file) but many of which would likely require some heavy extra configuration. I never even got into replicating things like live templates which are a massive productivity booster for me - I simply gave up.

For me it’s much easier to install the vim plugin in my IDE or editor of choice. I get the modal editing goodness of vim with a supercharged layer of utilities that work out of the box.

I'm not going to argue with your personal choice or that you should spend time configuring vim.

I'll just point out that the things you've discussed are possible in Vim if you want them.

E.g. live-templates (snippets) https://github.com/neoclide/coc-snippets

and that if you don't want to spend the time configuring yourself projects like https://spacevim.org/ exist.

Now there probably are some IDE features that vim can't replicate with plugins but it's very rare to see someone actually provide an example of one.

Something like a profiler with flame graph might be an example. Things like refactoring, completion or fast command search probably aren't.

The most important part of my point is not that I believe that they can’t be replicated, it’s that an IDE offers them with a time investment that’s nearly zero (I spend a couple hours per year fiddling with my IDE settings, tops).

I’d add that I am also quite doubtful that although they may be replicated, in many cases there aren’t going to be gotchas and UX problems not present in one of the popular IDEs. I can’t remember the specifics but I know that when I set up code completion in vim it wasn’t nearly as good as the one in my editor.

Never heard of spacevim but I have tried a few other “plug-and-play” vim adjutants like Pathogen and always ended up running into problems and spending more time on the issue than I had signed up for. Might solve some of the problems I mention, but I’m afraid it’s too late for me.

My IDE does everything I need and more, working out of the box on all machines I own (they’re not even that powerful) with fantastic UX and minimal fuss. I’m a Jetbrains guy so it costs me 6€/month but amortized per hour spent it might as well be free. If I wanted to save that nominal cost I’d go with VSCode, which I’ve worked with before and is nearly as good.

I’d turn this around and ask, why would I ever switch to pure vim?

> I’d turn this around and ask, why would I ever switch to pure vim?

I don't think that you should.

I'm only addressing the point that vim can't be used to do IDE like tasks, which with LSP support it clearly can

...but right now you will have to configure it if that's something you want. If it's not then you're good to go with your favourite IDE already.

There are things like refactoring which technically are supported by vim extensions, but are just utterly inferior to the dedicated IDEs.

For example - you know "extract method" refactoring. Pretty basic thing and I assume vim can do that. But on top of that when you extract the method, Intellij will go through rest of your code and try to figure out if some other parts could be automatically refactored to use this new extracted method as well. It will offer to change the method signature if needed to do that as well.

Intellij will - as you type - notify that the code you're writing is structurally duplicating an existing code and offer an intention to automatically refactor the code to remove the duplication.

Intellij offers an integration with databases - in my code I use a lot of SQL queries - intellij can connect to the data source and scan the schema. When you then type queries into strings, Intellij recognizes them as such, offers autocomplete to the tables/column and validates the query for correctness (also allows you to click through to the actual data view). It understands like 20 SQL dialects and things like JPQL as well.

Another example is the deep flow analysis which can point out logical mistakes as you type (things like NPEs). This is very helpful in daily programming, extreme example of that is shown here: https://blog.jetbrains.com/idea/2019/11/intellij-ideas-stati...

Most of the time when people showed me a "vim IDE", it looked like IDE from the 90s - highlight was that it showed you the list of class members, had a snippet manager and could sort of rename a variable. State of the art is much farther since the 90s though ...

That sounds very useful and it's not something that vim gives you out of the box but I'm not sure that anything you're describing is not possible via LSP plugins and extensions.

Running a server to automatically search for duplicate code sounds exactly like the kind of task that LSP can handle.

Since VSCode has tools for deep flow analysis (although I can't say how they compare to Intellij) then I'm pretty sure I can access them from neovim.

Maybe if I was a Java developer something like Intellij would look more attractive but I've never really been impressed with the rest of the JetBrains IDE family.

Horses for courses I guess. If there's some tool you want that's only available in Intellij then that's what you'll use.

All of that is of course theoretically possible with LSP or other vim extensions. It's just that nobody did it.

Another thing is the level of integration. There are many tools which offer static analysis, duplicate detection etc. But it's completely different level of usability when you see this info immediately as you type.

People already use LSP in vim/neovim. Realtime feedback as you type is a thing in vim.

Here is an example for typescript users.


Again this does require you to configure things and that may not be what you want to spend your time doing but it's perfectly possible.

Also I'll add that I'm not arguing that vim is better than any other particular IDE or editor, just that IDE like features can easily be added.

Yeah, I know that you can use LSP in vim. But LSP for most languages is a far cry from what you can get in "real" IDEs.

It's always "LSP could be just as good" or "support for that can be easily added" - but it's just not happening - nobody does the work to make that just as good.

Hated Vi at first. Absolutely loathed it. I was all about emacs.

But I gave vi another shot, and I'm so glad I did. The learning curve can be steep, and it's really unintuitive at first (or it was for me). But once it clicks a little bit, and you settle in.. Wow. I felt way more productive using it than any other editor.

I've been using vim for ~8 years now as my editor at work. I don't even use the "fancy" movements that everyone always brags about. It's still way more convenient to move around in than any other editor I've used.

I don't know where I saw it, but the idea that "Code exists to be read" really resonates with me. I don't care how fast I can crank out code. I care about how efficiently I can hop around from place to place to grok what is going on and how it needs to change.

The killer feature of vim that I feel like very few people know about is it's remote editor feature.

Launch a long lived instance of vim with a `servername` set, for example I do: `vim --servername EDITOR`

Then set up a application shortcut that will open the file using the prefix `vim --servername EDITOR --remote <file>`

When you open a file, it gets opened in your single vim instance.

From there you can navigate between all your open files using `:b <file-tab-complete>`

It's really a joy to use. You don't have the mess of tabs where you run out of space super fast, you just have a bunch of open files that you can switch between super easily by name.

This just sounds like a nightmare to me. I can't stand it when I have a terminal program with an unseeable list of files/panes that have to be opaquely navigated through. I very much want to be one of those vim/emacs ninjas but I just don't see how this is more ergonomic than Jetbrains where any file - not just 'open' ones - is readily available with all sorts of search methods with a single shortcut. And then I can visually see what files I'm working with instead of groping around through one file at a time in the dark.

> I just don't see how this is more ergonomic than Jetbrains where any file - not just 'open' ones - is readily available with all sorts of search methods with a single shortcut.

I would guess the difference is that I use a separate terminal window for all of that stuff. I have my desktop split into three main workspaces. The first has my terminal, the second my browser, the third my editor. I have two more workspaces just in case, but they rarely get used. I have shortcuts set up to hop between workspaces using `<super><workspace number>`.

If I want to track through where something is used or defined, `git grep` usually gets me what I want. From there, if there is a file I want to look at, I use my shortcut `go <filename>` to open it. This used to be an alias for `gnome-open`, but a couple years ago they switched it to `xdg-open` . It opens the file with whatever program would open it when opening it from the file browser, which for any text file is my vim instance over in workspace 3.

I don't pay much attention to which files are open or not. Usually I build up a working set of files I care about pretty quickly and then I can hop between them from within vim. Otherwise I can easily go back over to my terminal and open it by name directly.

It may not be for you, but it's far from a nightmare in my experience.

> It may not be for you, but it's far from a nightmare in my experience.

Right, everyone has their preferences. As was said in another comment, merely paying attention to and adapting one's personal tooling is a huge differentiator between software developers, regardless of which particular tools those might be. Your setup has a lot of conceptual similarities to mine. I use terminals heavily, but ultimately I personally like a GUI as the 'root' of my working space. I'd rather start from a place where I can navigate everything visually/spatially and then add shortcuts on top of that to automate the most repetitive/tedious paths that naturally occur in that environment.

Vim can operate like that if you want. Most people use NerdTree to have all of their files visible like most IDEs: https://code.tutsplus.com/tutorials/vim-essential-plugin-ner...

>The killer feature of vim that I feel like very few people know about is it's remote editor feature.

Now this is dope, I used to rely on a trick I discovered in a conference[0], append to the `path` variable in your .vimrc so you can recursively fuzzy find files in the directory where you opened Vim, and more recently setting global marks[1] in the files of interest.

0: https://youtube.com/watch?v=XA2WjJbmmoM

1: https://vim.fandom.com/wiki/Using_marks

(Helpful tip) map caps lock to escape: https://vim.fandom.com/wiki/Avoid_the_escape_key

Strongly agree -- I mapped my whole keyboard to always have caps/esc swapped. It didn't take long to get used to. My left hand feels way better, not needing to reach very far.

Biggest downside is using someone else's keyboard. I've grown a nasty habit of hitting escape instinctually, every time I finish typing something. I turn on their caps lock so regularly! Still worth it though

I still use caps lock since I regularly code in POSIX shell, C, C++, and Perl, which all have naming conventions that use all-caps names.

Also, as a VIM user, I only have to use Alt when I’m dealing with GUI apps, which is definitely common, but a time when I don’t mind moving my hands around.

So for me, Esc is Alt. Alt is caps lock. And of course caps lock is Esc.

And I swap Super key and Control, since the Super key is easier to press with my palm on my ergonomic keyboard. And Ctrl does have a lot of uses in Vim.

I also map the Windows Menu key (not the Super key, but the other one which is used for showing context menus) To underscore. That helps me type C identifiers with multiple words in them. This one remapping is a huge benefit, almost as important as mapping caps lock to Esc.

Still wasteful. Map Capslock to both Escape and Ctrl and never look back

https://github.com/alols/xcape (for linux)

https://apple.stackexchange.com/questions/132564/how-can-i-r... (for macOS)

https://github.com/ililim/dual-key-remap (for windows)

What's the advantage to having control on it as well? Do people have trouble reaching the control key?

Try it (or swap caps and control for day, to make sure you don't accidentally "cheat"). On most keyboards reaching the control key is very unergonomic compared to the capslock key. I wonder how many cases of RSI could be avoided by this simple tweak alone.

Map caps to ctrl and you can get access to a world of convenient insert mode shortcuts.

ctrl-[ (for right hand) or ctr-3 (left hand, thanks teddyh) => escape

ctrl-i => tab

ctrl-h => backspace

ctrl-m => return

ctrl-w => delete prev word

ctrl-u => clear line

ctrl-o => cmd mode for 1 cmd

...and many, many more, including all the completion options.

I strongly agree, but would go one step further and just remap caps lock to escape for the entire OS. Caps lock is a relatively useless function that takes up extremely prime real estate.

Or if you're on a locked-down computer because your office hates people, ctrl+[ works as well (and is portable to other people's computers)

You can also do the remapping in hardware. Programmable keyboards are quite popular these days (I built one out of a $3 stm32f103), and they don't rely on the OS to help you do what you want to do.

(This is a blessing and a curse. You never have to worry about OS-level hacks to make caps lock a control key, but on the other hand, there is no way in the USB HID protocol to say "send an !". Rather, the keyboard has to synthesize a shift + 1. And what character that actually maps to depends on your OS, because of course it does.)

I still get some mileage out of my caps lock key and use "jj" and use paste mode if I have to insert an uncommon string with "jj" in it. Usually pasting it anyway.

I tried that `jj` or `jk` thing for a while and it just did not click with me at all.

I tried it because I was having a bunch of wrist pain. The actual solution to my wrist pain was easy: Don't code on a laptop keyboard. The ergonomics are terrible.

I went one step further and swapped escape and caps lock keys on all my machines and haven't regretted it so far.

I cannot remember the last time I wanted to use CapsLock--more than 30 years ago, anyway.

By far the most irritating thing about others' keyboards is they have not disabled it yet. Second most is that Ctrl isn't there instead.

How do you TYPE_A_CONSTANT for the first time, or an ENUM_VALUE (perhaps somewhere you don't have autocomplete)?

I keep a caps lock on my programmable keyboard for this (Fn+K).

I also like SQL to be formatted with capital letters for keywords.

Either using shift keys or:

  type_a_constant ctrl-[ vawU
That sounds more than it is. Really I just touch type it without thinking consciously about it.

Probably don’t even need visual mode that’s just how I work.

I prefer Ctrl on Caps Lock and Escape on the original Ctrl. Works pretty well too.

One thing I like about vim is that the defaults are more sane than emacs. Almost no one uses emacs out of the box without extensive customizations. People customize vi too, but out of the box it is already pretty close to being there on its own, which is really nice.

I've used vi for 25 years now, starting on a m68k based BSD machine. It's an adequate editor, handy in remote shell sessions and good to know how to use, but I'd MUCH rather use an IDE or a windowed editor with menus and mouse and hotkeys like Sublime. I mean real hotkeys, not emacs.

At the end of the day, it takes a certain kind of mind to like vi, and if you're not of that mind, you probably never will be.

My argument isn't that vi/vim/neovim are not superior editors but the editing grammar is a superior way of thinking about text. This grammar can be reasonably replicated in any environment, and confusing the grammar for the editor is what makes people make such claims.

This is coming from someone who lives in vim for his daily work, likes it, but always finds annoying sharp edges that are hard to reason about and script away.

I think it depends heavily on what you're doing. My world is full of YAML/HCL/cnf files, and if I'm writing code, Go, where code is for software that runs from the command line, a daemon, or a no frills API/web service. Atom/VSCode and other IDE's were wasted on me, so I found myself gravitating back to Vim for its ease of use for those use cases. That said, vim-bootstrap did save me effort of getting a pretty solid editor out of Vim without having to think too hard about it.

Of course IDEs are wasted on Go - there’s literally not a single IDE in the world that can find all implementations of an interface in Go.

> And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective

Same here. Love high ROI tools where the rug doesn't get pulled from underneath me ever year or two. Linux console tools, bash, vim, etc. My vim config dates back 20+ years, with only small modifications. I can log in into just about any *nix machine made in the last 30 years and be able to edit text at least somewhat comfortably. It takes me 30 seconds to set up a fresh Linux machine to my liking: clone a repo and run a script to symlink things to the right places in home dir. Done. I can also comfortably work from anywhere in the world over a crappy SSH connection.

C++ is the same. Glacial pace of change, skills from 20 years ago are still good with minimal modifications. 20 years from now it'll still be in use and it'll still be about the same. Which is exactly how I like it.

Another good thing about these gnarly old tools is that they weed out the dumb and impatient. I strongly suspect Rust is the same way - the learning curve and feature set look formidable. Lesser engineers are unlikely to ever learn it to the extent required to enjoy working in it. There's value in that, so I might learn it as well once they stop screwing with the core libs. I have work to do, I have no patience for such things.

> C++ is the same. Glacial pace of change, skills from 20 years ago are still good with minimal modifications. 20 years from now it'll still be in use and it'll still be about the same. Which is exactly how I like it.

This gave me a bit of a chuckle since any modern serious C++ work is really a different language since 2011. Most of the C++ prior to that are considered anti-patterns now. It's hard moving at a glacial pace; the language gets major evolutions every 3 years.

If you like vimium, you may also like qutebrowser. It's built with keyboard bindings from the ground up, and is keyboard-first. I can browse most sites without taking my hands off the home row.

I use both QuteBrowser and Firefox with Vim Vixen, one of the thing that make me reluctant to switch completely are mostly addons, Multi-Container, cookies auto delete, ublock origin, Privacy Badger, ... I can't browse the Internet without those, and the built-in adblocker of QB is unfortunately not that performant. Also, you can't use the keyboard everywhere (thanks to the modern web) Random example off the top of my head: https://questions.wizardzines.com/event-loops.html

> and the built-in adblocker of QB is unfortunately not that performant

With "performant", I assume you mean "how well it works", not "how fast it works"?

FWIW a better adblocker is in progress: https://github.com/qutebrowser/qutebrowser/pull/5317

> Also, you can't use the keyboard everywhere (thanks to the modern web) Random example off the top of my head: https://questions.wizardzines.com/event-loops.html

Yay... You can always customize the hints.selectors setting to add selectors for those (for websites you use a lot).

There are also some thoughts on how to add hints to all elements with a JS click handler, but I haven't had a chance to take a closer look yet: https://github.com/qutebrowser/qutebrowser/pull/4817

> With "performant", I assume you mean "how well it works", not "how fast it works"?

Exactly, sorry, not a native speaker.

> Yay... You can always customize the hints.selectors setting to add selectors for those

Didn't know about that, thanks

The way I use qb is I've switched javascript.enabled to false, and occasionally session-enable it for some sites (by default, this is done by typing tsh)

I have also written off a portion of the web as not being worth mytime, however.

never heard about qutebrowser and it can even play netflix, impressive, it's a little memory hungry though, with just netflix running I saw memory is used almost 1GB, while 30 chrome tabs use 4.5GB

I was interested in programming, don't really know why but the thought fascinated me to be able to instruct a computer to do things you want it to do. So I had tinkered with QBasic and Pascal. A friend of mine went the C/C++ route which lead to us arguing like cat-and-dog (surely out of boredom) about the various benefits.

Then we mutually tried out linux and editors. He picked Emacs, so I went with vim. Haven't regretted it ever since.

I was in the same boat. First real gig out of college (well besides the stints during college) and I saw how fast my boss flew on his keyboard while editing files in vi/vim. Here I was painfully editing config files in nano while he was flying by with vim.

I took the time to learn it and have been using it since. I now try to pass the torch by showing folks on my team the neat things vi/vim can do. People are amazed how much you can do it with just few short keystrokes.

What has always kept me from learning Vim is my non-English keyboard layout. Many of the default key combinations are impossible or require some serious finger acrobatics.

Sure, I could try figuring out a new set of easily reachable and non-conflicting keybindings for my own machines, but much of my motivation for learning it in the first place was being able to work on remote machines more comfortably.

Try out a US* QWERTY keyboard for a few months. I grew up with non-English keyboards, but then some years ago I got stuck with a US keyboard for half a year, and after that I didn't want to go back. I can easily type the few non-English characters I need with the X.org compose key, so I can easily write in my native language. I assume it would work equally well for any language using a Latin-script alphabet.

*) US, not UK. UK QWERTY is trash.

Interesting point, and a good reminder of how anglocentric the computing world is in some ways. Do localized IDEs typically take this into consideration?

This is really interesting.

I'm quite the opposite. I keep trying to make vim my main devtool but I just can't stay away from a fully fledged ide. At the same time, having heard from literally everyone that once you do get used to it, vim is way faster to do everything in.

What advice do you have for someone like me to proper get used it once and for all? Are there any good resources you used to learn all the vim shortcuts?

My advice would be to start with the bare minimum: Using [i] to enter insert mode, [ESC] to get back to command mode, arrow keys to move around in either mode. With this you can use vim like Notepad.

Then observe yourself doing stuff and whenever you think "there must be a better way to do X", find out and learn how to do just that. (You would ideally have a cheatsheet on your desk for quick reference. If it's not on there, search the internet.)

At this point, it also helps to know about the basic grammar of normal-mode commands: motions as subjects, commands as verbs. Full sentences are either only-motion, command-motion, count-command-motion or command-count-motion. So if you have already learned that "dw" deletes a word, you immediately know that "d2w" or "2dw" deletes two words.

There's not much more to it. Just do your actual text editing and if you ever find yourself thinking "there must be a better way to do this", that's another learning opportunity.

It's a lot like language learning, really. You can plow through 10,000 vocabulary words in your SRS if you want, but nothing beats actually using the language.

There are a number of vim plugins (like YouCompleteMe [https://ycm-core.github.io/YouCompleteMe/]) that can turn Vim into an IDE. If that isn't enough, you could try Emacs (yes, I know) with an evil-mode based distribution like DOOM Emacs [https://github.com/hlissner/doom-emacs].

install vimtutor on your system, or just open this in vim:


It's a great start.

Personally, I find most modern IDE features are overrated and not necessary for productivity. For example, context-aware autocompletion is not necessary -- simple autocompletion based on things you've recently typed or that are open already in another buffer covers at least 90% of autocompletions I need. For the rest, I just have to type it out myself once, and now it is remembered too.

The same is true for browsing a file tree of your project, using syntax linters or reformatters, etc -- all of these are pretty straightfoward to setup in vim or emacs.

It can get a little tricker when dealing with breakpoint debugging, though. But in those cases, I just open in another IDE anyway that has extensive profiling tools, which vim does not have. But that's maybe once a week at most.

You don’t learn Vim that way. Once you get the Vim grammar, you just flow. Verb-adverb-noun.

This helped me back in the day: http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressiv...

Same as you. I've ended up accepting that whatever the features or the plugins, the UX constraints in terminal editors (1-character unit of space, colors, graphical plugins...) will always be a huge limitation. That's reason enough to convince me to use VSCode or Webstorm with a vim plugin

MacVim uses the Mac’s graphical goodness to make a pretty slick interface for Vim.

I like vim, it's efficient.

This comes from an emacser. Emacs who shares this trait a bit (albeit rarely installed by default) .. when sublime text was all the rage I saw how emacs had 50% of it builtin and the rest was absorbed in a few monthes. I felt emacs would never fade at that point.

I think this is the truth for me.

I have learned hundreds of tools and IDEs over the years, and nearly every one is defunct and not used any more.

Every minute I've invested in learning vim has remained relevant and useful.

Same experience here. Before learning vim I never expected its interface to make such a difference (it seemed daunting and unergonomic). I think the only other software that has made me feel that way is i3.

> And since, almost nothing else (save for maybe git) beat learning vim from a return on investment perspective.

Interesting. I generally use IDEs Pycharm or Eclipse, or VSCode depending on the language. Do you think I would gain a lot from learning VIM?

No. It's like when somebody wants to learn how to fly, people tell them first to learn how to run really fast.

Nowadays Vim isn't just Vim the text editor but rather a specification for text manipulation. All of the popular IDEs have Vim plugins and the benefits of learning both are perfectly additive.

I think your timeline is inverted. vi-style text manipulation has been a thing long before Vim.

I don't think I've claimed otherwise? Still, in my timeline those plugins aren't called IdeaEd or VsEm.

I dream of the day when Excel will have a vim mode... My life will finally be complete.

Perhaps you should give sc-im a go. It's no excel but a good enough spreadsheet with vim like keybindings.


Thank you!

Controversial comment here, but I would say Vim isn't popular at all. I would say instead, Vim advocates are incredibly vocal (a bit like Vegans and Crossfitters) and won't hesitate to talk about it at all times.

I've been engineering now since 2002 so approaching 20 years and sure, every office has one guy who's the "hardcore" Vim guy. Everyone else in the office uses Visual Studio or VSCode, Atom, Sublime, IntelliJ etc. But the "Vim guy" is the by far the loudest guy in the room when it comes to discussing his editor, tries to tell everyone else why their editor sucks, how superior Vim is, etc etc. Meanwhile all the users of VS and other editors quietly get along with their work and feel no reason to advocate for their editor like it was a religion.

At my current company it's the same. We have maybe 300 engineers. 99% of them use VS or VSCode, there's probably one or two guys using Vim and still telling everyone else they're dumb for using VS... In 50 years when things have changed completely, there will probably still be some guys using Vim telling everyone else they're wrong for using VR Coding with voice recognition (or whatever is happening in the world of coding then).

In my experience, after University, I never see team members extensively dispute on this topic. I have a strong preference for Vim, but if other are fine with other tools, that's nice. We can possibly show each other how we manage things differently.

It's not like Vim is perfect, and even taken the sharp learning curve apart, there are many things that are not ideal. But so are other tools. I tried some IDE here and there, but never found an improvement in my productivity – which would be certainly easier to improve by not going to sites like Hackernews. :D

I do find some things in some IDE horrifying, like having the amount of RAM consumed by the application displayed in the default interface, and seeing it growing while you don't ask anything to the application. I mean, even dropping the fact that it does require so much resource to do nothing, what a strange idea to clutter the interface with this data if the goal is to let users focus on there issues.

But that's no reason to be zealot of any other editor, including Vim. I'm rather confident that going with a matrix with measurable metrics, Vim wouldn't have rated 100% everywhere nor any other tool would.

To me the greatest feature of vim is that it's available virtually everywhere, so you can take it and the skill you gained on it everywhere. It doesn't make it something should use all the time, but it makes the point on how it might worth the effort to start learning it. That also a positive retro-active loop, that explain "why Vim is so popular", I guess.

> there are many things that are not ideal

I’ve never used vim, mind sharing what it’s weaknesses are?

Code browsing and inspection is somewhat hampered by the fact its CLI.

I use ctags and macros to move around code but its not always perfect.

But then again there are many things I dislike in modern IDEs, I don't think there is a ideal solution, just like there is no one language to solve all problems.

> Code browsing and inspection is somewhat hampered by the fact its CLI.

That's interesting because code browsing and inspection are by far the most important reason why I use a modern IDE. I tolerate all their weaknesses (slow, high memory consumption, errors after updates, etc.) because of this. I am surprised that somebody would say "I am using editor XYZ despite its weaknesses in code browsing and inspection".

It's always seemed to me that vim and other lightweight editors are most popular among people who are working in dynamic and functional languages, and heavyweight IDEs are most popular among people who are working in big, static, enterprisey OO languages like C++, Java and C#.

I don't think that's just a coincidence.

Vanilla Vim I would agree is not good for code browsing and inspection, but two things I've noticed when coding with Vim:

1. Code Browsing is an initial, one time cost when learning the code base. After you learn the code base, I've needed this ability much less.

2. Adding plugins like NERDTree and fzf/ripgrep have helped make code browsing much easier in Vim. The downside to this is that if you're new to Vim, you need to learn how to use these plugins on top of learning how to Vim. So it's just more to learn. But you can also think of this as another one time cost in general.

This is true for me too, I would often use Vim to basically do quick modifications, and use an IDE for refactoring/completion, and code navigation.

Recently a lot of quality plugins have been made leveraging Microsoft's languageserver capabilities to provide many of these features for NeoVim/Vim:


In many cases it's better than an IDE because the code-inspection, linting, etc etc, can be done using the same exact tools as what your CI is using behind the scenes.

Also, having a languageserver for Rust/C++/JavaScript/TypeScript/Bash etc etc, all configured through coc avoids a lot of the jumping between IDEs/editors/tools to get reasonable completion and code navigation between each.

What Vim lacks in browsing/inspecting code it makes up for with the speed you can make edits - using motions and macros can make tedious code changes nearly effortless.

So it depends on what you value more.

I've been a Windows admin before but now on an app support team running almost all Windows systems as an analyst but came from a poly sci degree. My Linux experience is homelab and a few work connected systems over time like a Ubuntu Server box that managed IP cameras on site. My experience with coding is mostly Windows automation via PowerShell and its built into Windows IDE as I need a dev role here to get like Visual studio. Even then it would be overkill for what I'm writing like temp cleanup, file transfer, monitoring, etc with my recent success was a script that checks every day for a set of reports we should have received and ingested overnight and lists what is missing then emails that info to myself and another team member. Super helpful to double check the business has the reports they need at the start of the day and get us a head start troubleshooting.

With that in mind, I've used VIM for probably under 10 hours total, mostly for editing config files within headless Linux installs. For example, setting a static IP in Raspbian so I could SSH in once I put the pi somewhere it was online but not physically accessible. VIM is really neat for stuff like that. I'd love to have more reason to learn the interface but barring a weekly use I'd quickly lose familiarity and am focusing on javascript functionality as one of our apps can run js scripts.

So for quickly editing files with a known structure like setting an IP address in Linux or updating code you understand, I can totally see how VIM is amazing. Lightwight, almost always there already so standardized, quick to navigate when familiar, and more. As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding, even for a slight update to something I wrote the previous day. I'm just not confident in getting it right the first time and know how to test or trial/error a command in an IDE much easier than CLI. If I was trained and focused on coding I bet I'd be way better at that stuff too.

> As a fairly novice level coder I'll stick to an IDE with scroll ability and a mouse/etc for coding

Check out gvim - it's a graphical version of vim that gives you scrolling and mouse support.

It's not quite as graphical as a regular IDE but basic stuff like mouse and scrolling is fully supported. You can even use the mouse to e.g. resize tiled windows within the editor.

There are graphical versions of vim. Gvim is my main editor. It's a bit of a hybrid, since many things that would exploit the GUI in an IDE are still textual in vim. But it has quite a few benefits over pure command line.

Did you not read TFA?

~25% of web devs in the SO 2019 survey said they used VIM as their editor. Amongst dev-ops that number is higher, around 40%.


So your anecdotal example of "99% of people using VS or VSCode" doesn't ring true for the industry as a whole.

People could select more than one option in that survey (87,317 responses; select all that apply). You'll notice that the results add up to more than 100%. Most people who have to remote in to a server will be forced into using Vim sometimes, which will skew the results. Also, I would say that people who would respond to a SO survey arent a representative sample of all developers.

I do not use Vim as a daily driver at all, but I have to use it sometimes because I have no other choice (remoted in to a box). So if I had to say which editors I used, Vim would be there... sometimes.

You're misinterpreting that graph. The key detail to note there is that the bars don't add up to 100%. Meaning that it's showing what percentage of people use that IDE/editor at all. The phrasing, "~25% of web devs... used vim as their editor," implies that 1 in 4 web devs use it as their primary or preferred editor, which is not something that can be inferred from the data.

For my part, when I answered the survey, I checked vscode, intellij, vim, jupyter, emacs, and rstudio. Most of those are there because they're my preferred editor for some task or other, but vim is only there because it's the only editor I can expect to have available on every server I ssh into. So, while I did say that I use vim in the survey, I would encourage you not to count me as a vim user for the purposes of any popularity debates.

FYI, the guidelines state:

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

I think it's highly industry and probably project dependent.

If company policy is that "we use X", then probably you're not going to have many people stray from that. The bigger the organization, the more likely you are to have strict guidelines in place like that.

I would guess people on Windows are also less likely to reach for Vim than any of the many other alternatives. If you're using Linux, you probably have a different view on the world to begin with, and are more likely to go with vim over whatever is the "new hot editor". I've heard Mac users like to reach for XCode, but I don't actually know many developers outside of work, and none of them use Macs, so I don't know.

Besides the other facts mentioned by the other commenters, Vim has a sort of geek-chic aspect to it. It's "cool" to be a Vim user in certain circles. That inflates the numbers plus it also causes a "New Year's resolution" effect where someone would say they use it just because they know :wq and this year they're really, really going to go to the gym, oh, sorry, going to use Vim proficiently for a real project.

Almost every editor allows you to interact with it as though it's Vim. But most editors don't allow you to interact with them as though they're any other editor. I think that's a point in Vim's favor?

(I certainly don't use Vim for most of my coding. It's not good enough. But I do use Vi keybindings in VSCode, Visual Studio and PhpStorm depending on what language I'm using. I'm not particular enamored of VSCode either, btw, for the same reason that Vim isn't good enough - sure, it can do what you want. But you can't guess how to do it. You need to read the documentation. VSCode one ups Vim in just one way - it has a gui for searching and installing plugins. Visual Studio and PhpStorm allow you to browse the menus to find the facility you want. It may take for ever, but when you have some downtime, you can browse and use your learnings next time.)

This. I just want hjkl and dd in every editor, but I don't use any other vim idiom often, and things like multiple cursors or alt+up/down move lines are the editor's fancy features I rely on most. (Sadly the VS Code vim plugin is broken all the time)

But hjkl I need even in my webbrowser. (In Thunderbird I've send many mails to junk by accident.)

Pretty much this. I'm learning Godot and love almost everything about it over Unity... except that its IDE doesn't have a vim-mode, which is ALMOST a deal-breaker.

I use Autohotkey to map Caps+H to Left, etc. systemwide

As a data point, Mac OS native text controls have a handful of Emacs-style text commands that use Control -- like ^t, ^e, ^h, ^b, ... -- baked in.

That is too bad. I'm a Vim user and combine the best of both worlds: vim plugin in VSCode.

A few of my colleagues are vim users, and fortunately for the others we are not as vocal as you describe. I already accepted of being the weirdo that uses vim, because my programming skills make up for it ;).

I do have a shortcut to disable it, when we do some pair programming.

> vim plugin in VSCode.

How is that these days? I used it a couple of years ago but it had issues at the time, namely some performance problems and getting stuck in a particular mode.

I ended up abandoning vim bindings because the JetBrains plugin was also buggy, and I straight up had no feasible way to get those bindings in Xcode, but I hold out hope for a glorious LSP-based future where I can just use vim and get all the benefits of my other editors.

There are a few. I am using VSCodeVim[1] with the default settings (besides the typical `jj` command)

I love it, and using anything else feels weird. I remember having some problems with it before as well, but I haven't bothered looking at the settings or anything for months. I had to go back just now to see if I had any weird configs set up, (I don't)


If you haven't already, you might want to check out coc.nvim https://github.com/neoclide/coc.nvim

Coc.nvim is awesome. Instead of trying to bring the UI of vim to another editor, coc.nvim brings the "backend" of the other editor to vim.

I tried using VSCode with the Vim plugin for a while but the latency and inconsistencies eventually got me back to proper (neo)vim. UIs are almost always more complex and subtle than people intuit, have a large surface area, and make lag and inconsistencies most noticeable.

Most vegans are actually quite quiet about it, so it’s a sort of survivorship bias, where you simply have no way to find out how many non vocal vim users out there :)

Saying vi and vim are not popular is like saying Unix and Linux are not popular.

Being at a company where most people do not use Vim definitely has caused a great deal of consternation and discussion about why I use Vim, and why I don't use a "real" IDE.

It becomes a hot topic of discussion without my wanting or really worrying about what other people are using.

I think the comparison to Veganism is a good one--- people think it's a flex, when in reality I just like it and it helps me get my work done.

Have you considered that every person who uses vim has sat down at a new job and been told by their boss how much they're going to love their IDE?

> I would say Vim isn't popular at all.

The fact that most popular editors and IDEs (every one you mention) have VI/VIM plugins suggests otherwise.

It's (usually) not the editor itself that people find appealing. It's the key bindings. It's the fact that you can navigate around a file without reaching for the mouse.

I sent this comment to my colleague, I'll see if it triggers him... :-)

> VS and other editors quietly get along with their work and feel no reason to advocate for their editor like it was a religion.

Well of course not, because their editors SUCK!

Well, I am the only guy on my team who uses VScode-Vim and I don't preach. I understand that editor is a personal choice when it comes to development.

So Vim has more champions. Sounds like you experience ineffective ones all the same.

Software engineering is far bigger than your niche.

sounds a lot like the IRC guy...


IRC users don't use vim, but nvi. They don't need any more. They probably use entr(1) and make(1).

I think they are just being posers. When we compare the efficiency of debugging (p. ex.) it is clear who can find the problem fast.

Today if I'm conducting an interview and the someone tries to convince me he/she is a good programmer and just use vi/vim, I need to rethink my decision because it can compromise the whole project. I'm not saying they are not good, but having the capability of fast debugging and solving problems fast is crucial sometimes and is part of the whole package.

I was that kind of person someday and I understand the feeling.

But for devops, vim or emacs are the all-in-hands tool and everyday editor, just because they are available in everywhere and work very well on terminal mode.

Interesting comment. I've been programming for more than 25 years. Have used stuff like GWBASIC, TurboPascal/C , fancy ide like VisualStudio, Eclipse, Netbeans and the new kids like atom or vscode. I even used DDD at some point.

Line debugging becomes less and less valuable as you become more mature in you dev career. Sometimes you have a race condition bug, some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.

In my experience it is more valuable to improve skills of building mental models of the system at hand, get effective with console logging for key info and troubleshoot issues that way.

>some times the target architecture just doesn't provide it (devkitpro/devkitarm or embedded) and sometimes bugs that are evident in production just cannot be replicated in your debugging environment.

It happens, yeah. What mostly happens is that 99% of software development has debuggers available and that they are infinitely better and more useful when resolving issues. Printing, then realizing you don't have enough info, chaning your code, recompiling, printing, etc, is just not good software development practices.

Live with your constraints when you have no other choice. Use the tools that have been a standard in the industry when they are available to you.

Spoken like someone who has never gotten accustomed to the power of vim :)

Do you know who would likely "compromise a project"? The junior dev that is unable to stray outside their IDE when getting things done.

IDEs are great for the early stages of a project, but once it hits production, this is the only debugging flow that has ever worked for me:

1. Read the logs.

2. Read the code that produced the logs.

I don't get it. Are you saying vim users are bad programmers and bad at debugging?

I believe the assumption is that IDEs are dramatically superior tools for debugging.

he's saying vim users are hampering themselves.

I think you should evaluate candidates based on the skill/knowledge they show in the interview and trust that if that is up to par, then they will be competent to choose the tools that work best for them.

Disappointed the article went straight from punch cards to video terminals without mentioning teletypes.

> Having that thing show up on computers in those days was pretty tricky, and some considered it a resource hog.

Well in the 60's and 70's, you didn't necessarily even have a display, you might be using a physical teletype. `ed` is built for that.

Even when you had a display, it could be slow. The VT05 from 1970, only went up to 2400 baud. And if you were using a modem back then I think you were definitely most likely connected at 300 baud or below.

Perhaps my favorite video on YouTube is this glorious footage of someone hooking a 1930s teletype up to a computer running Linux:


Watching it for the first time is what finally made ed click for me.

And yes, I was disappointed that the author clearly didn't understand why ed has the UI it does. It's about the teletype, not the computational cost of having a WYSIWIG UI.

I desperately want to set up a teletype on my modern desktop - there’s just something so awesome about electromechanical interfaces with a lot more mechanical than electro.

Agreed. I have some mechanically-minded young sons who I'm hoping to introduce to computing by way of a teletype of some sort.

Yeah that video is all kinds of amazing. I also got lost down a several hour rabbit hole watching the guy and his buddies bring up an AGC and perform a simulated lunar landing with it. Thank you for sharing!

That video is amazing!

Or the display might be a single line of 16-segment LEDs for interacting with the machine, and "output" was on paper. Another reason to keep the visuals to a minimum.

> ed

Ed is the standard text editor!

[0]: https://www.gnu.org/fun/jokes/ed-msg.en.html

Does anyone have a good video comparing vim speed coding vs vscode using built in editor features?

I’ve been using vscode for years and the YouTube videos that demo vim features are shallow (like how to enter a blank line - really?). I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings all while being able to edit code instantly without changing modes.

I would love to see a fair comparison between someone using vim at 100% and someone using vscode at 100%.

Of course some vscode shortcuts might not be fair (like F12 to jump to definition, F2 to rename every usage, etc.)

But even in raw editing:

With vscode, I can do multi-line editing, I can navigate quickly, jump to specific words, etc all very fast.

If there is no video like this, would anyone be interested in a race?

There's too many little things to mention, they do all add up to be quite significant in the course of programming.

Here's a tiny sample of some stuff I use constantly:

Move cursor forward word at a time: w ignoring punctuation: W reverse: b B

Move cursor to next occurrence of character Z: fZ reverse: FZ

Delete forward to next occurrence of character Z: dfZ reverse: dFZ

Change forward to next occurrence of character Z: cfZ reverse: cFZ (like delete but leaves in insert mode afterwards)

Repeat latest edit from current cursor position: .

A lot of the vi commands are composable, as illustrated to some extent above.

To search for say the next line starting with void: /^void

To delete from the current line up to the next line starting with void: d/^void

Note the similarity to dfZ/fZ from above, it's not 100% consistent but most times you can take a chance composing things as you'd expect and things work correctly.

There are far more sophisticated things too of course, but I'm not writing a vim tutorial in an HN comment.

You can do things like rename a function while rearranging its arguments either file-wide, or on a number of lines, or on an interactively selected visual region, or a section selected similar to d/^void... I presume other editors have such capabilities, but I'm most familiar with vim. In vim the actual renaming and rearranging is done using a regular expression containing backreferences:

  s/old_func(\([^,]*\), \([^)]*\))/new_func(\2, \1)/
You may constrain that to a subset of lines a variety of ways, and on top of that can suffix a 'c' on the end of the substitution regexp to make it conditional and you'll get a chance to interactively yay/nay the substitution at every match in the considered lines. The conditional suffix is a godsend as it lets you be fast and sloppy with your regexps and just skip the false positives.

Honestly, I can do almost all of these things with any standard editor as well, with standard shortcuts.

The ones I can't do directly, I can do via Search/Replace functionality that is also standard in most modern editors.

Your example about refactoring a function by using text editing capabilities is actually pretty bad unless you mean Vim can actually parse your programming language and perform the refactoring over all your code-base (not just a single file), like any IDE will do.

This list you gave me just convinced me I don't need Vim.

Here's the real question - So you are convinced you don't need Vim, right? Why are you on this thread?

No one's saying vim is superior. However, you need to have an open mind to understand the alternatives.

It's not like Vim is a paid product and by you not using it, Vim is going to die out soon or anything.

If you dont' like it, great? You are happy with the alternative, great. You seem like you just want to deliberately start an argument and then prove you are right, but why?

I am in this thread because this is not a thread about how Vim is great, it's a thread about how Vim became popular, which I honestly don't understand in a day and age where modes are completely unnecessary. I see lots of happy Vim users telling the rest of us how they are so happy with Vim and they can't understand how anyone can do anything without it... so I thought I should point out I feel extremely productive on any non-mode text editor (all my shortcuts work even in this HN editor, on a browser, in Word, basically anywhere except old editors like Vim). Been programming for nearly 2 decades now and even when I started, I thought Vim was a tool from a time when we didn't have Ctrl and Arrow keys and we already had better alternatives.

At this point, I feel like "I use Vim" is like "BTW I use Arch", said usually with an air of superiority as if choosing "the hard way" was somehow smart.

which I honestly don't understand in a day and age where modes are completely unnecessary.

Modes are everywhere. My microwave has a defrost mode. Cars have reverse mode. Pill bottles have modes where the bottle has to be held differently to open it.

Modelessness isn't all it's cracked up to be.

I’ve used many editors on the Mac—BBEdit, SubEthaEdit, Chocolate, TextMate, TextWrangler and a few more obscure ones.

I switched to Vim and haven't looked back nearly 10 years ago because the "modeless" editors had limitations and issues I didn't like.

I used Emacs when I worked at MIT because that's what everyone used, but it never took for me when I had to use Unix.

What the author didn't mention is that when Ruby on Rails was the new hotness, so many of the leaders in that movement were Mac users, on TextMate. But when TextMate went into limbo, and then eventually died, that tribe needed a new editor and they essentially all moved to Vim.

Many of the early Rails videos were done on Vim; they were quite influential.

I wanted an editor I wouldn't outgrow in a few months and Vim fit the bill nicely.

And to this day, I feel like I'm pretty proficient with Vim but I also know I'm using like 10-15% of what Vim can do and it's nice to know all that capability is there for when I need it.

So if I understand you correctly you're angry that people choose to work in a way that you think is unnecessary and that they're just doing it to show off.

I can't speak for other vim users but I think it's pretty obvious to us how other users work without vim and we know you can be productive without it.

Personally I make a point of not telling people to learn vim but equally I think, for example, not having a shortcut to repeat a complex visual selection is a pain.

I never feel the need to enter a thread about IDEs and point out this missing feature (especially if it's a program I don't actually know well and that might not be the case).

However I often see people that don't know vim well make statements like "vim can't do x" without actually checking if that's true.

Then we look "superior" when we point out how to do it in vim.

It's hard to win because your argument sounds like an emotional one.

To win what? This is not a contest or even a debate where one point of view may prevail... we're just expressing our opinions about Vim and its alternatives here. Obviously, if you like Vim, great! But it seems to me you're the emotional one if you find it necessary to question anyone pointing out they believe Vim is not a good tool at all (it promotes modals, which should have died as soon as they became unnecessary due to hardware improvements as they are objectively harder to use) and wondering why it's still somewhat popular.

I use vim as a boring config editor in terminals. I don't think it's the best editor by a long shot and even something as basic as Atom is more productive for code editing for me. The idea of customizing your vim setup for maximum productivity doesn't appeal to me. It always ended up in a mess and over ssh it's pointless.

You may want to check out “How Vim killed Atom and VSCode on my Machine”—-https://medium.com/@aswinmohanme/how-vim-killed-atom-and-vsc...

One neat trick that vim has out of the box that most other editors/IDEs don’t is a tree based undo system.

So if you undo something a few steps and try something different but decide you want to go back you can’t... but you can in vim with g+ and g-

If you add the Gundo plugin you can visualise this as a tree of diffs in a side window.

I’m sure that’s been added to IDEs as a plugin but in vim it’s standard.

It also persists undo state to disc if you want so if you return to a file on another day it’s still all there.

Another neat thing:

You select some text, either via keyboard or mouse. You realise you’ve missed a bit at the start of your selection.

In vim without having to start over you press o and it moves your cursor the other end of the selection and you can now extend it.

Deselect accidentally and want the selection again? Press gv.

I’m sure these little features are available in other editors but not always or not always by default.

wow i never knew these, great suggestions!

> Honestly, I can do almost all of these things with any standard editor as well, with standard shortcuts.

WTF is a standard editor and standard shortcuts? Would that be ISO or ANSI?

Also what is “almost all” in this context?

Isn’t that just another way of saying I can’t do these things but don’t care? The Blub argument effectively.

So I am a fan of vim and have used it on and off for 15 years at this point. I generally use IDEs or VSCode these days instead for writing code. Here's my take.

I think the popularity of learning vim might be similar to what jiggawatts mentions as the 'perception of speed', especially for tools in the UNIX world, as well as being 'the hard way' like you mention. But I think there is value in learning how to use vim. I see the advantages of learning vim are programming language agnostic. Vim is focused around words and text, treating them as objects, and creating a mental map of keystrokes to modify those objects. I think it's somewhat analogous to typists that hunt-and-peck vs touch typists. Opens up a lot of productivity, but it's definitely not needed to be a writer.

I agree vim has many limitations. It has a not so great language for scripting, no out of the box setup for stuff like refactoring or renaming symbols in your codebase, GUI feels like a second class citizen (IMO, compared to the terminal version). In a lot of ways, it might not hold a candle to the likes of VSCode, Atom, Visual Studio, XCode, IntelliJ, Eclipse, etc.

The nice thing is that you could add a vim-like plugin to any of those IDEs/editors to match the spirit of vim, at least in terms of navigation. It's not like you need to stay in vim to reap the benefits of the mental model.

I think that's where a lot of the power and appeal of vim is. Vim is still drawing a new generation of programmers, artists, and hobbyists to learn this strange text editor, with its unique but powerful way of interacting with text.

Honestly, I can do almost all of these things with any standard editor as well, with standard shortcuts.

As a 30-year Vi/Vim/NeoVim user, I can confidently say, "No, you can't."

The parent described only a fraction of what vim can do. The notion of text objects and combining them with plugins makes vim much more powerful. Even without plugins mastering vim makes writing code quite natural.


Thanks for the feedback.

vscode has regex find replace, but I don’t use it very often. It does show every match highlighted in the current file while entering the find value, which is nice.

It does the same for multi files if needed and gives a nice preview of every change.

Word navigation I use a great deal (especially with multi-cursor editing). Ctrl+left/right jumps words, home, end to begin end of line.

Ctrl+f Z Enter would go to next Z value. (Which I don’t use, because I don’t think in partial words much, but rather jump to mouse if I need to navigate far)

That’s probably where I could gain in using that instead of going to the mouse every time.

Ctrl+arrow is almost as bad as going to the mouse. The thing with vim is you rarely have to leave the home row.

Some other random things I use constantly (I am not the person you're replying to):

C — replace to the end of the line

xp — swap two characters (which I have to use more frequently than I'm willing to admit.)

ci( — replace everything in brackets (like the arguments of a function, this also works with " or ' for strings, { for blocks of code, and so on). The cursor doesn't have to be inside the brackets, it'll jump to the nearest match.

:earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d

. — repeat the previous command (this is much bigger than it sounds, as it allows you to repeat the same complex manipulation on different data in situations where you can't use multi-cursor, but which don't warrant building a whole macro.)

A ton of custom filetype- and mode-dependent <leader>-based bindings (which is the spacebar in my case). space-space to jump to definition, space-f to reformat the file, that sort of stuff. This can probably be done in vscode.

If you're really interested, there are tons of vim videos on youtube made by real vim pros. I am very far from being one. The best for me are live coding sessions where vim usage is demonstrated by doing the real work, not on some toy examples.

> :earlier 10m — time traveling, which comes in handy between commits or with config files, especially if you configure vim to write persistent change history. What did this file look like a month ago? Oh yeah, :earlier 30d

Another trick to my bag, that's why I absolutely love these threads about Vim.

:later also works (hence the joke that you can just hit :later 8h and go home...)

On a Mac at least, ctrl+n/p/b/f/a/e all navigate text without reaching for the arrows, with the added benefit they work in every application. I quit vim because I prefer using a smaller but universal set of navigation that works everywhere from Xcode to VS code to the terminal or typing in Chrome.

Ctrl-arrows is not the same thing as vim’s wordwise movement. If you need to go 5 words forward, it’s 5w ; if you want to capitalize the next 3 words, gU3w ; the point is composability, not a single operation. Same goes for f.

I guess I, and maybe other non-vim users, just don't see much use in the composability. From many examples I've seen in this thread, the only one I found truly interesting was the branching undo feature.

For most features, the advantage seems very small, as the use-case is so rare, or it's not the limiting factor anyways.

But this is very limited to my experience. I am pretty sure, if I already knew those things, I would value that investment the same way the vim users do in the vim threads. But for now, it seems to me, that the investment is not worth the payoff and I am better off learning something else.

I use the vim plugin inside of VSCode and it's perfect for me. I would never go back to just VIM, or just an IDE. but my best use case for vim modes is stuff like: [c]hange [i]nside ["], where wherever your cursor inside inside of a "string", you can just press ci" and can immediately start typing a new string to fill it. And then this same thing can be changed to ci{ to change everything in {} to change a function, or ci( to change a function's paramaters, etc.

Then theres stuff like [c]hange un[t]ill [x], to change everything up to a certain character.

or [y]ank [i]nside ["], to 'yank' (copy) the text inside of a string and be able to paste it immediately anywhere I want to. It's verbs and sentences that you're writing in VIM modes.

Do modern editors have these kinds of keyboard shortcuts?

In general I think vim users are extremely bad at explaining why vim modes are so good, as I never use 5w. Am I really going to count how many words ahead I have to go? No, i'll just press [f]ind char to the word I have to go to.

The biggest thing about vim is that it doesn't make you more efficient or faster, it just eliminates the time you have to think about how to edit text once you internalize it, which I know doesn't sound likely because the keybindings are so strange. But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code

Actually I never wondered if there were shortcuts for those, so your response prompted me to check the keymap of m PyCharm. There definetly are many extended ones, but doesn't seem to cover all of that and are not as composeable.

> But know that I've learned it, i genuinely don't think about it, and every time I'm not in VIM and have to move my mouse and click on a character I feel like I lose my train of thought of where I was in the code

I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things. I'm not really actively thinking about it either.

Thanks for taking the time to share your thoughts!

> I believe that, so please believe me when I tell you that I just have navigation with the mouse and other shortcuts internalised for many things.

Definitely! I just want to provide an actual reason for why VIM is great as people who are very into it are the worst at telling you why it's good.

It's usually, "well if you spend 3 months tinkering with configurations and plugins, you can basically have most of the features an IDE has out-of-the-box!" which misses the entire damn point of vim.

Also it's great because if you're ever ssh'ing into servers, you can be confident that you can be close to as productive editing files there as you are in your IDE, which I find very re-assuring. But as it is right now, I don't see a reason why anyone should switch to vim unless they enjoy the act of learning it and want to get some of the cool composability features, which are just fun to use and learn

> I just want to provide an actual reason for why VIM is great

Thank you for that, I value it! It seems I was unneccessarily defensive!

> if you're ever ssh'ing into servers, you can be confident that you can be close to as productive editing files there as you are in your IDE

That is a nice point.

> Delete forward to next occurrence of character Z

How often do you really do things like this though? It seems like, sure you can do weird obscure things quicker in Vim, but only if you happen to remember how do to the weird obscure things, and it's only useful in weird obscure situations.

For 99% of tasks the built-in VSCode stuff does the job for me. Ctrl-D especially.

> How often do you really do things like this though?

All the time. Some examples:

* ct, : "change up to comma", useful for replacing a function argument.

* ya" : "yank around '"'", copy the string literal the cursor is currently inside.

* ci( : "change inside '('", useful for changing the condition in an "if" statement.

* da{ : "delete (i.e. cut) '{'-delimited block", useful when changing the structure of if/else blocks.

I agree that these commands may sound obscure, and many Vim users use the program for a long time without using them (I certainly did). But when you start using them, you find that these composable editing commands correspond really well to many of the logical editing actions you perform.

I don't use vim, but this feature seems mostly useful for deleting things within marking characters, such as " and ', which I do surprisingly often. (But not often enough to learn a shortcut to do it)

Not that specific example, but you'd really be surprised by how useful some of these things are. For example you can do a `di[` to delete everything inside an array. Or `ci"` to replace everything inside a string.

Very often, actually. It's something that pops up quite a lot when editing code, and you want to remove/change a chunk of text.

In the very comment you're replying to I already said "stuff I use constantly".

Here's a video of some more advanced vim features I threw together. I'd be surprised if you can do this using e.g. vanilla vscode


Its a simplified version of a problem from work a while ago where we had to generate ui from lots of csv files. The last dev on it was taking weeks, but with vim I was able to come in and finish the boilerplate instantly. (We were commited to non-dynamic ui at that point, I think I made the right play especially with how we ended up using it).

Vim is, in my opinion, inferior to an ide or a good text editor, but if you have it as a plugin you get the best of both worlds and vim suddenly can do... basically anything you can think of. Like here's putting a breakpoint on every line in a file


The best part of vim in an ide is when you're pair programming and you do something fancy, and your friend says "Wait, go back, howd you do that??"

That’s pretty cool. It seemed a bit slow creating the “macro” but pretty cool to see it run through all the lines.

The way I would do that in vscode would be with a multi-edit, but it would get iffy at that many lines.

I‘ll record a video doing the same for comparison tomorrow.

This makes me wish there was a site for recording challenges like this where developers could race using their favorite tools.

Vim vs VScode would be an amazing way to learn tips from experts on both sides.

Nice vim demo on youtube, how does the sequenced numbering work? Can vim increment a number without any plugins?

Ya, basically go up, grab number, go down, paste number, increment number, go down, repeat 50 times. Needed for generating xaml that had row and column #s from the csv, interestingly excel could gen the code too relatively quickly.


copy 10 lines from the current position into buffer q, go to the start of function jnk, copy 5 lines into buffer w, jump to line 10, paste contents of q, contents of w, and contents of q sequentially one after the other:

"q10yy /jnk "w5yy 10G "qp "wp "qp

now, go to the start of the document and indent the next 20 lines by 10 spaces:

0G .,+20s:^: :

ok great, now find JUNK and replace 'a1' with 'A1' in the 15 lines that follow:

/JUNK .,+15s/a1/A1/g

probably not as efficient for multi-file refactoring, but for raw 'drag race' style text munging, everything is there, loaded in muscle memory, and under the home row of your keyboard so you don't have to lift your hands at all.

Thank you for that example!

Just thinking out loud how to do that in vscode for comparison:

- I don’t think repeating actions a specific number of times makes sense in most use cases. Counting 10 lines would take longer than doing shift up/down n times (which would be exact with feedback) to select the desired lines.

- Multiple Copy Paste buffers sounds interesting, I might look up a vscode extension for that. (Had a copy paste queue in Visual Studio but it would break sometimes and would lose something important).

- go to start of function jnk, there are many ways to do that in vscode. Ctrl+f jnk enter would be one.

- Goto start of document is Ctrl+Home

- Indent 20 lines by 10 spaces, could do Alt+PageDown, then up/down to get to the right place (without counting or caring that it is exactly 20 lines), then with multi-line insertions could space,tab, etc.

That operation would probably justify mouse usage though, in which you simply hold alt, drag ~20 columns/~10 cells and hit space - which itself would be faster than counting 20 lines.

- find junk: ctrl+f junk enter

- select 15 lines (shift+page down,up/down to adjust) I can preview I have selected the correct area, other possibilities to select current function, etc.

- Ctrl+h to replace, a1 tab A1 Alt+L Enter

- of course in most cases, I am renaming a symbol, so “F2 A 1 Enter“ would do

I think the reality is that counts are not known before hand, so being able to increment/decrement with visual feedback is perhaps faster than a miscount, but I’d have to see it to know.

Anyway, thanks for the detailed examples! I can certainly see how it would be powerful if committed to muscle memory, but even with vscode there are many shortcuts I don’t use because of formed habits.

I have a plug-in installed in vim and vscode (and ilellij) that provide me with relative line numbers in addition to absolute line numbers. So, the current active line might display "353" in the gutters for the 353rd line. Both the line above and below are 1. The next lines above and below are 2. And so on.

There is never any "counting lines". If I need line's number, I can do a quick addition/substraction in my head or j/k $offset to see the other line's absolute number.

I can do line-based operations a lot faster than shift-tapping or click-dragging, with exact precision because my editor has been customized to provide the data I need. Eventually you get pretty good at estimating line numbers and character columns too.

cheers :)

for line counting - indeed a good point and clearly required for the examples -

After time, eyballing this becomes a skill. For things that fit on a screen (~50 lines or so, give or take) I'm usually correct 1st time or within a few lines. I can check quickly by moving the cursor (20j to go down 20, 20k to go back, repeat if necessary to get the line count)

also as others have pointed out, I might not be doing the best/optimal thing for some of these, just some examples of how I do things that popped in my head :)

> Counting 10 lines would take longer than doing shift up/down n times

Vim get round that by providing the option of relative line numbers to the current line.

That’s accessed via

  :set relativenumber

I find it interesting how we use vim so differently. I'd never type "10yy", I'd use "y9j". I never use "10G", I use ":10<CR>" (<CR> = enter for those not familiar). Similarly, "0G" is "gg" for me. Call me a notepad user, but that whole second snippet for me would be "ggV19j>" followed by "." until things lined up correctly. Similarly, the third would have been "V14j:s/a1/A1/g".

Nit pick: "q selects register q. A buffer is a different thing.

yep - probably a few ways to do things and I might not be doing the cleanest, just the way I learned/figgured it out

> now find JUNK and replace 'a1' with 'A1' in the 15 lines that follow

The real scenario is usually to replace, for example, in a function block. How do you do that? Counting function lines seems like a non-starter.

If the language uses curly braces to define blocks, it's easier: ciB. Parentheses are easy as well: cib. Otherwise, I'm not sure there's a good solution currently. You can substitute by indentation with a plugin (https://github.com/kana/vim-textobj-indent/blob/master/doc/t...). For Lua, I usually do c/end<enter>.

I believe this is an area where treesitter can help, so I'm looking forward to Neovim's integration.

Highlighting the initial { of a function and then typing 'va}' ('v' for entering visual mode, and 'a}' moves to the matching close brace. Similar commands work the [], (), and <> pairs) selects the entire function body. From there, a regular s command will operate on the entire selected text.

Mine is v% :)

You know these aren’t new issues, right? Vim has been around since 1991 and back to 1976 from Bill Joy’s editor.

Of course Vim can replace a function block easily and has been able to do so for decades.

Ok, also am curious about multi-insertion with cntr-left/right that vscode does:

For example, let’s say I have a json object with variety of field names, one per line and I want to remove the quotes.

With vscode, I can alt select all lines, Home Ctrl+right del cntl+right del.

The trick is the field names are different length, does vim have multi-edit with the ability to navigate relative to each insertion point?

Edit: Here is a good video example (https://youtu.be/iomWEDMBlcE)

Can vim do something like that?

There are things that vim does better. There are things that VS Code does better. There are things that Visual Studio does better. You can memorize all sorts of things about your particular editor of choice and you will be more efficient and effective in that editor.

If I wanted to cherry pick examples of what vim does better, I could start all of them with, "first ssh into a random server."

What makes vim great is that it has a tremendous number of features and is available nearly everywhere. Can VS Code do that?

VS Code can (sort of) do that: https://github.com/cdr/sshcode

sshing into a server invalidates all the time you spent on customizing your local vim.

If you’re on your machine, you can do all of your stuff because you can edit files remotely from within Vim using SSH as the transport: http://usevim.com/2012/03/16/editing-remote-files

If you’re on a new machine, you can grab your dotfile repo from wherever you keep it—like GitHub for example—and you’ve got your complete config, since there just text files. Takes 5 minutes.

But even plain vanilla Vim is more than enough for many tasks on a new Unix/Linux box.

Not if you use Emacs/evil. Tramp invalidates most of the "well, vim is available on all my remote servers, whereas Emacs never is". I just remote into a server from within Emacs.

Evil is also the best and most complete vim experience outside of vim.

For your use case there are a lot of ways to do that in Vim without using the multi cursor, here[0] is one thing I just recorded to show you a glimpse of what's possible with just a search and replace: I just find a pattern and replace it with a part of the same pattern.

> Here is a good video example (https://youtu.be/iomWEDMBlcE)

Again, you can do everything here without using multicursors, just record a macro for one line and repeat with a count and you're set.

Now if you absolutely want the multicursor feature, there are more than one plugin[1][2] for that, but I never felt the urge to use multiple cursors in Vim.

0: https://youtu.be/YR7rRC-vwj4

1: https://github.com/terryma/vim-multiple-cursors

2: https://github.com/paradigm/vim-multicursor

There's a couple of ways you could tackle editing that depending on what your json looks like.

For example you could use the visual block mode (ctrl-v) and highlight to the end of the line using $ and then use A to edit the end of every line at the same time. That works with lines of different length.

Or you could use a regex inside of a block selection.

Or there's a multi-cursor plugin available for the same approach as you're currently using in VSCode:


Vim Golf is an excellent resource for seeing how to efficiently edit things in Vim: https://www.vimgolf.com/

I vaguely remember there is a plugin that does multi line edits - what I never found useful.

I personally would rather use :s (search-replace) for that. Regexp is your friend.

Jump to definition and rename every usage are really handled by the language server. Vim supports language servers quite well. I do both those commands in vim all the time. And vim complements them with (book)marks, return to last edit, etc.

Vim can jump to definitions and stuff too. It integrates with ctags. It can also do code completion and everything else. I have it bound to clang-format with ctrl-k.

Just feel the urge to mention cscope which is ctags on steroids

And LSP is yet SO MUCH better

Heard good things about it, but I'm on an endeavour to learn how to do things with Vanilla Vim first to avoid abusing my use of plug ins for things Vim can handle gracefully ootb.

Now you're the creator of autojump, I just want to say your software is definitely a time saver, especially with this https://github.com/fdw/ranger-autojump, keep up with the great work.

I'm with you with avoiding too many plugins. But LSP is not just another plugin, it's the standard for languages to implement IDE support. I find it hard to justify not using it if you're doing serious software development (depending on the language of course).

Thanks for the kind words on autojump :) I'm no longer involved with the project, but I feel the general idea is still relevant.

Between the awkward file navigation and the feeling of building my own editor from the ground up, I just never found it worthwhile to fully commit to Vim. So I work in VSCode in my day job.

What I did take from those efforts, though, was Vim's text navigation key bindings. They are a joy to use and most text editors have some sort of emulator for them. The beauty is in the chording, almost all of which maps to easily remembered mnemonics. Delete everything between quotes? Use di". Change curly brackets to square? Change surround, or cs{[. Once you've gotten used to switching between move and edit modes, you can layer these in bit by bit. At a certain point it becomes second nature and you do feel like you can edit code at the speed of thought. It's a powerful feeling.

> I can do the same thing I have seen in vim videos without memorizing a bunch of strange key bindings

you totally can! I could talk for a while about customization and ctags to address some other points you made but at the end of the day its a text editor, vim and vscode are both text editors. it sounds like you really like using vscode so you should stick with it, I really love vim and it works really well for me, and my boss loves using a near vanilla sublimetext 2 install. programming will never be about typing and editing speed but being comfortable with your development environment and hopefully even enjoying it is very important.

One vim hack I like is multi-line macro application. It's a good fallback in case, as I often forget the syntax for certain things. To facilitate this, I've remapped ctrl-space in visual line mode to apply my `q` macro to every selected line.

As an example, say I need to add a comma to a bunch of lines. I will record the macro on that line appending a comma to the end, visually select all of the other lines to copy the macro on, and then jam my hotkey to apply the macro.

It's often much quicker than reaching for a regex for short segments of code.

FWIW, your particular example is doable with vanilla Vim with the same efficiency (with less strain)

    V<count>j (3)
    :'<,'>norm A, (8 - The angular brackets are automatically added by vim)

    qq (2)
    A,<ESC> (3)
    q (1)
    V<count>j (3)
    <CTRL><Space> (2)

Here's my best take at this so far, I wrote it in 2007:

Why, oh WHY, do those #?@! nutheads use vi? http://www.viemu.com/a-why-vi-vim.html

This post has been my enlightenment about modal editing. Thank you for this excellent piece. And I've referred dozens of people to it after me.

My pleasure :)

I've found keyboard-only vim is much slower than a mouse for editing papers, because the edits are often random-access and vim isn't great at that. You also can't use SyncTeX (which is amazing) without a mouse.

Why would you use vim keyboard only since vim supports using a mouse in the terminal?

It even supports using a mouse over ssh.

I don’t know SyncTex so can’t comment on that.

There's no point in comparing them, in my opinion. VS Code is a tool for programming; I would call it an IDE but I 'm not very familiar with the app. Vim is still "just an editor". You can still use it for programming (not just coding bash scripts), but that's making your life harder than it needs to be. In my experience the amazing text editing features of vim are only very rarely useful in a software developer's work. I feel the same about multiline editing though. And Vim has amazing text editing features, but severely lacking code editing features.

If you care for them vim has access to many of the same features as VSCode via LSP and the same plugins that VSCode uses.

Why would one be suitable for programming but not the other?

It just comes down to UI preference and whether you want to configure things yourself or not.

My (neo)vim can do more than vs code in default config.

Both support plugins, so the possibilities are basically endless

Google "vim golf"

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact