Because its the only reliable way to edit a file when there’s a “house on fire” production incident.<p>Want to use xemacs? sorry you need a weird dependency. Ok lets use emacs. Still not installed. Ok lets use nano... wait how do i save this again?
I have always had a problem with all these emacs or vim plugins for various editors and IDEs. The problem is that as soon as you leave the context they work in - switch to a different window or a dialog box (or, in the case of Visual Studio, anywhere outside the code editor window), you are back to having to use the native key bindings.
Favourite vi joke ever: "I've been using it for about two years now, mostly because I can't figure out how to exit it."<p>On the other hand, it's everywhere, it's quick and once you learn it there's a lot of muscle memory that takes over.
What really makes coding environment productive for me are: file navigation,
code browsing, call hierarchy, class hierarchy, find usages, find declaration,
find implementations, refactoring, build integration, debugger integration,
documentation integration.<p>I did try vim more than once over the years. I'd use it to edit config files on servers but would much prefer an IDE for coding.
I'd like to stress the point in the article about how important the . is to efficient vim use. <a href="https://pragprog.com/book/dnvim2/practical-vim-second-edition" rel="nofollow">https://pragprog.com/book/dnvim2/practical-vim-second-editio...</a> completely changed how I use vi in this respect.
vim is a grammar, a true grammar, once you learn that, it all makes sense.<p><a href="http://rc3.org/2012/05/12/the-grammar-of-vim/" rel="nofollow">http://rc3.org/2012/05/12/the-grammar-of-vim/</a>
First of all the article is from (2007).<p>This is just another love letter to vi/vim that lists "misconceptions" people tend to have and tries to debunk them.<p>Me personally, I didn't have any of the misconceptions listed in there. My beef with vi/vim lies somewhere else. So let's tackle the question "Why, oh WHY, do those #?@! nutheads use vi?" and here is my top list of problems I have with vi(m)<p><i>1)</i> most people I know don't know how to use vi(m)<p>I know quite a lot of people who use it, but those people don't use any advanced functionality. They basically use it like this<p><pre><code> i
<do stuff>
<esc>
:wq
</code></pre>
some of those people recommend vim to other people and when asked why they use it all argue with how powerful it is and that it is installed "everywhere", but nobody uses the powerful functionality (anecdotally it's less then 10%)<p><i>2)</i> vi is installed by default everywhere - but what vi?<p>There is<p>* nvi (used in void linux in version 1.81) <a href="https://sites.google.com/a/bostic.com/keithbostic/vi/" rel="nofollow">https://sites.google.com/a/bostic.com/keithbostic/vi/</a><p>* ex-vi (used in archlinux) <a href="http://ex-vi.sourceforge.net/" rel="nofollow">http://ex-vi.sourceforge.net/</a><p>* vim-minimal (used in red hat) <a href="http://www.vim.org/" rel="nofollow">http://www.vim.org/</a><p>* vim (yeah ubuntu uses afaik "vim.basic") <a href="http://www.vim.org/" rel="nofollow">http://www.vim.org/</a><p>Then there are busybox vi, neatvi and neovim (that's what I use)<p>Anyway they all "should" behave the same, but they have non overlapping functionality and behave different (even depending on the terminal you use. I more then once had problems depending on the TERM variable set)<p><i>3)</i> you probably have to carry over you config wherever you go<p>Let's be real here. If you use vi(m), _really_ use vim, you probably have your default config. Maybe on github, maybe on your homepage, maybe on an usb drive or memorized. I know people with multiple vim configs for different use cases. The defaults I find are not usable for most. And some functionality doesn't carry over from vim to vi.<p>And even thought I say that the defaults suck, the default behavior changes from version to version. For example the smart indent functionality on older versions is different than it is now and they changed the crypto for the encryption (imho vim shouldn't support encrypting of documents anyway [see point 5] these were just the 2 examples that came to mind first). Meeh<p><i>4)</i> you have to use plugins<p>Yeah plugins are great. You don't have to use plugins, but you for sure _want_ to use plugins. With the right plugins vim can even be a really good IDE. But you have to manage them, update them and again: on every machine you use you have to carry it over.<p>What plugin manager do you use? vim-plug? vundle? pathogen? Or maybe something entirely different? You don't want to manage them by hand and you are gonna need one. So get comfortable choosing one and setting it up everywhere.<p><i>5)</i> vims original goal (afaik) was to adhere to the kiss principal<p>but it failed. vim now has the kitchen sink. If you install vim you pull in more than 30mb (yeah today it doesn't seem like much, but I like having a small footprint no matter what I do)<p>If you can read mails in your editor you are doing it wrong (sorry emacs users)<p>_____________________________<p>So the reasons why I don't like vim or why people shouldn't use vim aren't the ones listed on the site.<p>PS maybe you want to take a look at vis if you want to see what vim should have been.<p>edit. formatting
Vim is my main editor, my main gripe is that it performs terribly (without any plugins) with either relative numbers, cursor line or syntax highlighting in files larger than 200 lines.
I’ve found that a majority of people who use vi(m) and profess to hate Emacs because of the complexity of its shortcuts also spend their whole time in insert mode, using only the arrow keys for movement, leading me to think that these people just hate efficient editing in general.
This does not match my experience at all.<p>Most people I know use vim and the holdouts use emacs (except for Java developers using Eclipse).<p>No one in my circles thinks using vim is any cooler or harder than any other editor per se, but it generally meets people’s needs well.