
Why Should You Learn Vim in 2020 - ingve
https://pragmaticpineapple.com/why-should-you-learn-vim-in-2020/
======
mumblemumble
For what it's worth: I really don't care to tell people what editor to use.
But I do think that everyone should think about spending some time with
vimtutor. Not because it will turn you into a 10x developer, or because vim
has the best keybindings ever, or anything like that. I've never bought it.
But I _do_ believe that it is very likely to make your life easier, even if
you don't actually use vim.

Let me explain: I've been an emacs person for decades now. I was never super
committed to it, though. In practice, I'll use whatever editor has the best
plugin for the language I'm working in. Which means that, for the longest
time, I had to try and keep track of 4 or 5 different sets of editor keyboard
commands. Which is too damn much for one brain, so I found that, over time, I
stopped being as efficient in any editor as I was in emacs 25 years ago.

So why vim? Because every editor worth its salt has an option to use vim
keybindings. So you don't have to learn 4, 5, 6 different sets of editor
commands. You can learn one, and learn it well.

~~~
yodsanklai
> Because every editor worth its salt has an option to use vim keybindings.

I'm not sure about this. For instance, I'm typing this message in a text box
in my browser and I don't have access to vim keybindings. There are many cases
where this happens (other example: google docs).

I do use vim whenever I can, but I'd say the most useful keybindings that one
can learn are the ones from the OS.

~~~
justinator
Both Chrome and FF have plugins to add vim key bindings - at least for
navigating around the UI and the page. Which would support the argument to
learn them. I guess your argument would be stronger if there were other
$editor_of_choice key bindings for browser textboxes?

~~~
vmladenov
On macOS a majority of UI text fields support readline bindings (^A, ^E, etc)
which is really nice

~~~
jolmg
> support readline bindings (^A, ^E, etc.)

Those are emacs bindings. Readline uses emacs bindings by default, but it can
also use vi bindings.

Unless you mean that it uses readline and so configuring it (i.e. ~/.inputrc)
allows you to change the keybindings of macOS UI text fields. That'd be cool
if it's the case.

------
darintay
If you're interested in vim, but hesitant about the lack of IDE bells and
whistles, VSCode's vim bindings are so good - with full support for e.g.
splits, macros, buffers, ... - that I've finally converted to using that over
raw vim.

Most anything that VSCode can do, you can make vim do with plugins, but it is
often incredibly time consuming and finnicky to get up and running, whereas
with VSCode everything "just works".

All the productivity of being able to edit text in vim, alongside the
conveniences of a real, modern IDE.

~~~
i_love_limes
I'll add that all Jetbrains products (IntelliJ, PyCharm, WebStorm etc) have
the IdeaVim plugin which is also great, and it also respects some vimrc
configurations too.

I always loved vims movement and editing and hated it's file traversal /
project management, so this is a perfect amalgamation

~~~
modernerd
IdeaVim is faster and less laggy than VSCodeVim in my experience.

You can even use a custom ~/.ideavimrc and bind leader shortcuts to JetBrains
actions. I rarely ever touch the mouse in IntelliJ now. It's an ultra-
productive environment to have the power of IntelliJ, the convenience of vim,
and Spacemacs/Doom Emacs style shortcuts.

For example, to manage projects:

    
    
        nnoremap <leader>po :action ManageRecentProjects<CR>
        nnoremap <leader>pc :action CloseProject<CR>
    

Or to create/switch git branches:

    
    
        nnoremap <leader>gb :action Git.Branches<CR>
    
    

Or to bring up the nav bar to change or create new files (Ctrl/Cmd + N once
the nav bar is visible):

    
    
        nnoremap <leader>fn :action ShowNavBar<CR>
    

Or to summon git blame annotations in the current file (repeat to dismiss
them):

    
    
        nnoremap <leader>ga :action Annotate<CR>
    
    

Or manipulate windows:

    
    
       " Window movement.
        map <leader>wv :vsplit<CR>
        map <leader>ws :split<CR>
        map <leader>wd <C-W>c
        map <leader>wx <C-W>c
        map <leader>ww <C-W>w
        map <leader>wl <C-W>l
        map <leader>wh <C-W>h
        map <leader>wk <C-W>k
        map <leader>wj <C-W>j
        map <leader>wo <C-W>o
    

Or summon “Refactor This” at the cursor point:

    
    
        nnoremap <leader>rt :action Refactorings.QuickListPopupAction<CR>
    

You can get a list of available actions for your current environment and
plugins with the :actionlist command.

I only started playing with this recently but my current config is here for
those interested:

[https://gist.github.com/nickcernis/bcb5cb7f55c07ed3de8287d16...](https://gist.github.com/nickcernis/bcb5cb7f55c07ed3de8287d163ed7c28)

It takes a bit of searching and fiddling, but once you hide all the chrome (I
even hide tabs at Editor → General → Editor Tabs → Tab Placement = None),
install IdeaVim and configure shortcuts how you want them IntelliJ feels just
as slick as a tricked-out Emacs/vim, but with better out-of-the-box code
intelligence.

On Mac I also remap Ctrl+hjkl system-wide so that I can navigate IntelliJ
popovers with vim-ish shortcuts. I use Karabiner for this with the “Vi Mode,
left_control + hjkl. shift/option/command + arrow working” option on this
page: [https://ke-complex-modifications.pqrs.org/?q=%20PC-
Style%20S...](https://ke-complex-modifications.pqrs.org/?q=%20PC-
Style%20Shortcuts)

~~~
badhrink
Any idea if there is a way to check for presence of Ideavim in vimrc/init.vim?

I have a single config for all vim related things(vimrc) and source it for
neovim as well, hence I was curious. For example,

has('nvim') checks for neovim.

Something like this for 'ideavim' would mean I can add IntelliJ related stuff
inside that check.

~~~
modernerd
I haven’t tried it but there are a couple of suggested workarounds here:

[https://stackoverflow.com/questions/34528322/how-to-
include-...](https://stackoverflow.com/questions/34528322/how-to-include-only-
some-of-vimrc-in-ideavimrc)

------
nrclark
Agreed 100%, for anybody who has to use a Linux CLI with any regularity.

You don't need to be a vi/vim wizard, but you should at least be able to use
it a little bit. Vi is the one editor that's guaranteed to be available
basically anywhere.

For working on a complex file (local to my workstation), I almost always
prefer Geany or maybe VSCode (depending on the scope of the project). But I'm
also semi-decent with vi, and it's saved me a lot of times on embedded systems
where I need to log in via serial-console and edit some files.

It's also just faster/easier for editing the odd config-file here or there on
a system that I'm logged into. Sure, I could launch a GUI and browse to it
(for a local file), or maybe edit with a GUI over SSHFS or something. But if
it's a small change? Vim is killer.

Maybe Emacs is better for CLI use, I'm not sure one way or the other. But it's
definitely got a much smaller install-base than Vim. And proper-noun Vim has a
_much_ smaller install-base than vi-compatible things generally (vim, busybox
vi, etc).

------
brandonmenc
Unpopular opinion:

Programmers like using vim because it feels like solving a puzzle or RTS
micro'ing and/or they have already sunk a huge amount of time into it and
aren't willing to walk away (which is fine, but it's not evidence that these
tools are better.)

Starting fresh (i.e. no experience with an IDE or vi/emacs) there is zero
productivity benefit to choosing vi or emacs over a real IDE in this day and
age.

Disclaimer: I am a former vi (~5 years) and emacs (~20 years) fanatic.

~~~
minerjoe
A bit myopic. Programmers have many different needs and as with almost
anything - it depends. "zero productivity benefit" is blatenly false for many
people. Now for you, in your current needs, sure. But why attempt to paint the
entire developer world your favarite color?

------
n0on3
IMHO the reasons in 2020 are the same of the last few years and are not
changing any time soon: you don't need to leave the terminal AND it is
everywhere AND (once you get used to it) it is extremely powerful and blazing
fast (most "normal" people think vim users are having some sort of meltdown
when they see vim users do even pretty simple stuff).

TBH, although this might be an unpopular opinion among vim users, I don't
think vim is worth for coding beyond simple scripting, a decent setup requires
way too much work which defeats one of its key points. But for everything else
in editing files, nothing compares.

~~~
gizmo686
Not quite everywhere. At my current job, I have gotten somewhat proficient
with sed, which is the most advanced editor installed on our production
systems.

Also, for some reason, many modern systems still only install vi by default.
If you know vim, you know vi; but it is missing enough features to be
annoying.

~~~
gh02t
A lot of Linux systems (most as far as I know but could be wrong) actually
ship vim but in a very stripped down build and set up to run in vi
compatibility mode by default, e.g. vim.tiny on Debian and Ubuntu. BSD systems
often use nvi, which is quite close to the original vi, and can feel very
weird if you are used to vim.

------
auslegung
The reason I learned Vim in 2019 is b/c I wanted a lightweight, powerful,
ubiquitous tool. I was willing to overcome the learning curve, but it took
time. The most helpful advice I got was from this article
[https://medium.com/actualize-network/how-to-learn-vim-a-
four...](https://medium.com/actualize-network/how-to-learn-vim-a-four-week-
plan-cd8b376a9b85):

Week 1: Complete vimtutor once a day, every day Week 2: Use Vim with minimal
config, no plugins Week 3: Use Vim with minimal plugins Week 4: Compose Vim
commands with verbs and nouns

------
_virtu
I'm a vim user turned JetBrains user. I still use IDEAVim inside of all of the
JetBrains offerings. I go back and forth wanting to purely use vim but I can't
warrant all of the config overhead. To me that's the biggest reason not to use
pure vim instead of a vimulator.

The vim ecosystem reminds me of the node ecosystem. It's a choose your own
adventure approach. Yes, there are wonderful and powerful tools, but it's
always a shotgun of plugins to get a solution for each language you want to
support. With JetBrains, I get 90% of the tooling I need for the language I'm
using out of the box. The other 10% can be handled by plugins and some small
configuration changes.

I'm posting this because I want to be convinced otherwise. Here are the
JetBrains features that I can't live without:

    
    
      - Contexts: https://www.jetbrains.com/help/idea/managing-tasks-and-context.html#work-with-context
    
        - Re > I'm usually working with a 6 to 8 way split. Kind of like the tabs on my browser.
    
      - VCS tooling
    
        - Handles multiple git repos from a top level. I can commit across all repos or a single repo selectively
    
        - File change view
    
        - Merging view
    
        - Per line commit selection
    
      - Inbuilt database tooling
    
        - Ad hoc queries and output directly next to the code you're prototyping
      
        - Database introspection
      
      - Symbol based refactoring
    
      - Visual debugger
    
      - Multiple module repo
    
        - You can configure a language/ecosystem per each directory in your project to get the associated tooling for each directory
    
      - Scratch files
    
      - Local history
    
        - This has saved my ass more than once. It's amazing how far back you can go outside of commit history with this.

------
kasajian
I use Visual Studio 99% for my coding, and Visual Studio Code for 1%. I would
prefer to use VIM for editing code or any text because it's a 1000% better
than Visual Studio. The problem is, there's 50 other things you do with Visual
Studio that is not editing code, and for those things VIM is not that much
better, or better at all.

It's not even good at dealing with more than one file. Yeah, I have nerd-tree
and have tried explore. meh.

I'll think about it when ReSharper comes up with an add-in for VIM.

Yes, I know Visual Studio Code has VIM mode. . and Visual Studio used to (or
maybe still does), but then you're outside the norm of that environment. Ever
Visual Studio Code extension is tested with Visual Studio Code. But they're
not all tested with Visual Studio Code in VIM mode. That's why I like to stick
with defaults and the base-case.

What's needed is for VIM itself to have features beyond just editing text
files. It's never going to compete with Visual Studio or Visual Studio code
until VIM itself adds those features that make a viable IDE replacement.
Today, it ain't.

~~~
d33
Here's my suggestion: give neovim nightly a try. With built-in language server
support, many new features are easy to add. You can install it like this:

    
    
        wget https://github.com/neovim/neovim/releases/download/nightly/nvim-linux64.tar.gz -O- | tar zxvf - -C /usr/local --strip=1
    

And the relevant part of dotfile that adds LSP support and enables a few
language servers:

[https://github.com/d33tah/dotfiles/blob/master/dotfiles/vimr...](https://github.com/d33tah/dotfiles/blob/master/dotfiles/vimrc#L118)

You'll also need to run:

    
    
        nvim +PlugInstall +UpdateRemotePlugins +qa
    

Personally I was surprised many times how easy it was to add decent support
for new languages. It really is a godsend.

------
apotatopot
I use vim because its got :sp/:vsp, can edit remote files over scp, :E,
:earlier, and now :term, plus so many options in vimrc. I don't think I really
even need tmux w/ it anymore.

~~~
commandlinefan
Wow, I've been using vi for 30 years and I had never seen :sp/:vsp, :E,
:earlier or :term (although you can do :sp with ^W s). I always feel like
there's still a lot of "hidden" functionality in vim that I need to uncover
one of these days.

~~~
addicted44
:term is new with Vim 8 I believe.

The Vim author was against adding :term but their hand was forced by the
success of neovim from what I understand.

------
rsa25519
> Notice how quickly you can select characters along a column. Please let me
> know if there is a way to do this as quickly and painlessly in other
> editors.

Drag your mouse while pressing meta on VS Code. I certainly think Vim is
powerful, and I've spent enough time in it to be able to edit a file solely
via ex. But I think VS Code is making some awesome progress, too. I like using
the two editors together

~~~
com2kid
Almost 3 years of VS code usage, I can not remember _which_ meta key.

Doesn't help that I use a Windows keyboard on Mac some days, and a Windows
machine on others.

Also mice suck (but are orders of magnitude better than track pads), I always
find selecting columns this way to be super finicky and I often have to do it
twice to get it just right.

~~~
chipotle_coyote
As common as this argument is, I've always found for me that there's a
hierarchy in "ease of use" for text selection that isn't quite as simple as
"device X is always better". From quickest to slowest:

* Keyboard command that requires no counting or precision and has no easily-confused variants. In almost all editors this encompasses up, down, left, right, home, end, select or delete a line, and so on; some editors have more sophisticated ones like "select all in enclosing characters", or Vim's non-parameterized text objects ("cw" for "change word" as opposed to "dt6f" for "delete to the sixth occurrence of 'f' or maybe to the character in front of it, I always forget which").

* Mouse selection in any editor that lets you do multiple clicks to change selection object (e.g.: single click character, double click word, triple click line; on a Mac this is nearly any editor, including the text box I'm typing in right now). This _isn 't_ as precise as a correctly-executed keyboard command like "dt6f" or some Emacs equivalent, but it requires less cognitive switching: you don't have to think about the command and you don't have to do any counting. You just know you want to select from _there_ to _there._ If you mess up, it rarely requires any effort to recover.

* Keyboard commands that require you to think carefully before composing them. This is where Vim, god love it, sometimes falls down hard. I know exactly what I want to select, but I have to stop and think about the "best" way to select it, and if I screw it up, I have to get back to where I was and try again -- which may require yet more thinking. I don't doubt that there are people who are just _super good_ at this and get it right _first try evey time,_ and those people are... well, probably not much faster than someone who gets selection right with the mouse every time.

tl;dr: Mice do not suck, and I like trackpads, dammit.

~~~
com2kid
> Mouse selection in any editor that lets you do multiple clicks to change
> selection object (e.g.: single click character, double click word, triple
> click line

Keyboard does that better than mouse IMHO. Alt-arrow to skip between words,
alt-shift-arrow to select word to left or right.

Use correct meta or home/end key along with shift and arrow key to select the
entire line, based on your platform of choice.

I'd like to see some more intelligent selection hotkeys though.
JumpingBetweenCamelCase, "everything inside the quotes" { data:'inside',
the:'braces'}

~~~
chipotle_coyote
I think whether the keyboard is "better" than the mouse depends to a degree on
where and what you're selecting. If I want to start the selection at or very
close to where the cursor is at the moment, I'm going to use the keyboard; if
it's somewhere else on the screen, though, the mouse might well be quicker. (I
just experienced both of those when I wanted to change the last phrase in that
last sentence, and the cursor was all the way at the bottom of this comment,
then wanted to edit something just one line above. The latter case, keyboard;
the former case, mouse.)

> Use correct meta or home/end key along with shift and arrow key to select
> the entire line, based on your platform of choice.

Ideally this is just one command, I think, like Cmd/Ctrl+L for "select current
line". :)

> I'd like to see some more intelligent selection hotkeys though.
> JumpingBetweenCamelCase, "everything inside the quotes" { data:'inside',
> the:'braces'}

The only editor that I've found that does both of those out of the box is
BBEdit for the Mac, which uses Ctrl+left/right and Opt+left/right to navigate
and select by word but Ctrl stops for camelCase and underscore breaks while
Opt doesn't. And Cmd+B, "Balance," selects text between enclosing characters
in the current scope: brackets, parentheses, quote marks, etc. I'm not sure
why equivalents to these aren't more common in other editors.

~~~
com2kid
> Ideally this is just one command, I think, like Cmd/Ctrl+L for "select
> current line". :)

I find it easier to, instead of remember another command, remember "jump to
start of line, select entire line."

Mentally composable and it works in all text input boxes across the entire
system. (MacOS, cmd-l selects current line in VS-Code, jumps to URL bar in
Chrome.)

IMHO the problem is getting stuff to be system wide. Per editor hotkeys, or
even worse. hotkeys added by plugins, cause dissonance when I sit down at
someone else's computer, or just switch apps.

------
axegon_
Vim is absolutely awesome. I've been a heavy user for a good 15 years now, and
yes, I was a very weird kid. Ever more so now, since covid-19 hit us, and the
wfh saga began. I've been developing solely on vim. The only downside is that
by the time my working hours are done, I'm usually working with a 6 to 8 way
split. Kind of like the tabs on my browser.

------
erulabs
Was taught VIM by my mentor in the early 2000s, along with Gentoo Linux and
friends. I've since gone from sysadmin to "devops" to CTO - and VIM skills
still rank as some of the most useful. VSCode in VIM mode finally convinced me
that maybe being a developer isn't such a bad fate.

------
imran3740
I'd also recommend Neovim[0], a community-led fork of Vim. One of the focuses
of Neovim is exposing an API that lets other apps embed a headless instance in
their UIs. This lets you use your Neovim editor along with all its
configuration and plugins inside other apps! I've never been satisfied with
any of the available vim emulator plugins out there for VSCode, IntelliJ, etc.
(there's always something missing!), so this feature has been really valuable
to me if I need a better debugging experience but want to use nvim as much as
possible.

Someone's already made plugins that embed a Neovim instance right inside
VSCode[1] and Sublime Text[2]. There's no emulation here, just straight up
neovim running behind those buffers. I've tried VSCode with that plugin
(though personally I like to stick to just neovim when I can), and I can say
that despite some minor bugs it's been a pretty smooth experience. Even stuff
like `gt` to change editor tabs is supported.

[0]: [https://neovim.io/](https://neovim.io/)

[1]: [https://github.com/asvetliakov/vscode-
neovim](https://github.com/asvetliakov/vscode-neovim)

[2]:
[https://github.com/lunixbochs/actualvim](https://github.com/lunixbochs/actualvim)

~~~
adsjhdashkj
How does the Vscode and Neovim thing work though? I've tried to implement
something similar for Kakoune and Atom editor, but i noticed that Atom would
always manage its own buffer, and Kakoune as well, so i'd have to basically
duplicate the buffers - passing tons of data around constantly.

Does vscode-neovim work around this somehow?

------
andersced
I don't agree. I work in cloud / ssh environments all the time. My main
computer is a mac and I need to copy text to and from multiple machines and
the host machine. I write C++ and other languages on all the remote machines.
[https://micro-editor.github.io](https://micro-editor.github.io) is the only
viable alternative for me as its more modern and supports all the features I
would expect from this distributed environment.

~~~
chipotle_coyote
While I've only given micro a cursory look, it doesn't seem to have any
particularly unique features compared to Vim, and from all appearances it's
far less powerful. (This isn't the knock it might seem to be; it's hard to
match any editor that's been under fairly active development for 25+ years.)
I'm also not sure what you meant by "this distributed environment"; if you're
SSHing to cloud servers and running micro in a terminal there, that's
"distributed" in exactly the same way people have been running Emacs and Vim
for decades.

My main computer is _also_ a Mac and I _also_ need to copy text to and from
multiple machines and the host machine, and while I don't write C++, I do
write other languages on all the remote machines -- and BBEdit lets me do that
a lot more easily, since it has menu commands for save/open over FTP/SFTP. But
it's certainly not unique in that regard. (Personally I've found Vim's netrw
implementation of this a bit clunky and never got Emacs's functionality for
this working quite right, although "Never Got Emacs Working Quite Right" may
be my epitaph).

------
haolez
I don't think that the editing experience is the biggest selling point in VIM
(although it can be very good). I think it's the ease of creating and
integrating custom tools for the specific problem that you are dealing with,
sometimes even for one shot demands. It's orders of magnitude easier than
creating a plug-in for a mainstream IDE.

------
ropeladder
I use vim bindings with everything and am a full convert to modal editing.

But...

Vim bindings also feel like they have accumulated 40 years of cruft and
evolved into some severely localized maxima. I'd be really interested in other
attempts to do modal editing. Are there other attempts out there?

(Disclaimer: I use vim and vim bindings a lot but I am not really a vim power
user.)

~~~
NateEag
There are several within the vast expanse of Emacs extensions:

[https://github.com/mrkkrp/modalka](https://github.com/mrkkrp/modalka)

[https://github.com/fgeller/fingers.el](https://github.com/fgeller/fingers.el)

[https://github.com/jyp/boon](https://github.com/jyp/boon)

I believe I've seen at least one standalone editor focused on this, too, but I
don't recall where.

~~~
gabcoh
Could it have been [http://kakoune.org/why-kakoune/why-
kakoune.html](http://kakoune.org/why-kakoune/why-kakoune.html)

~~~
NateEag
Yup, Kakoune was it.

Thanks!

Edit: And, as had to be the case, someone has made a simple simulation of
Kakoune for Emacs:
[https://github.com/jmorag/kakoune.el](https://github.com/jmorag/kakoune.el)

------
simonebrunozzi
I learned vim properly in 1999. I was a power user back then.

Years later, I started thinking that sooner or later, a simpler, better
alternative would emerge.

It's 2020, and I'm still waiting.

------
austinl
People who are extremely comfortable with vim + tmux look like they're doing
straight up wizardry (probably the closest to what people imagine programmers
do in movies). I remember seeing one of these folks during my first
engineering internship and I was sold. Now I can't imagine doing most things
without vim + tmux + the_silver_searcher + fzf (vim plugins).

The biggest downside for me is I don't think autocomplete is on par with other
IDEs (even with YouCompleteMe, which is great). To be fair, this would be a
massive challenge, considering how generalized vim is vs. an IDE like Xcode —
which is purpose-built for writing Swift/ObjC. I feel like half of the time in
Xcode I'm just hitting tab, and the code writes itself. I want that same
experience in vim.

~~~
smabie
Try spacemacs and lsp. Or just vanilla vim and lsp. Should work for most
languages just as well as a real IDE.

~~~
AlexSW
I second using LSP servers. It's an absolute treat having an editor which is
completely independent from the backend intellisense, which I can add my own
LSP servers for however I choose.

------
major505
in all honest, is important to learn basic vim because is avaliable everywhere
and there's a nearly 100% chance that at least vi will be in a random remote
server you ssh into and needs to edit a quick config file.

That said, after use it extensive in the past, unless your editing code in a
potato, for more complex work, I don't see a reason to learn advanced
commands. You will be more productive with a modern text editor.

------
scythe
vim

\- opens instantly

\- does side-by-side file viewing with reasonable text size and low enough
clutter for a laptop screen

\- offers a great deal of editing power with no need for any extra preparation

Starting to work -- particularly at irregular times -- is much more fluid with
vim. I usually need to take a deep breath before opening an IDE. Vim is just
_there_ , at my fingertips, all the time, and few competitors offer that
experience.

~~~
Shared404
> Starting to work -- particularly at irregular times -- is much more fluid
> with vim. I usually need to take a deep breath before opening an IDE.

I can't even count the times I've accidentally written :w into a document
while using an editor without vim bindings.

------
bifrost
I've been an nvi user for around 20 year, vim ain't for me.

------
cosmotic
Almost every reason given in the comments in favor of vim is not mutually
exclusive to vim nor mutually exclusive with other features in other editors.
It's easy to find vim alternatives, including GUI applications, with these
supposed great features - and more.

The most significant, real benefit is the ubiquity, and the ubiquity is a
function of tradition, vim's size, and its portability. This leads to its use
because its 'the only option, not because 'its the best (or even good)
option'. There's no arguing against the benefits of the ubiquity; its on
almost every device that runs linux or unix like OS.

What really separates vim from the real day-to-day competition is the abysmal
usability. From the complete lack of visibility and discoverability to the
numerous modes, vim is a hall-of-shame when it comes to UX and UI. The
original post even points to this stack overflow question with 3k upvotes and
a top answer of 5k upvotes asking simply 'how do I quit vim':
[https://stackoverflow.com/questions/11828270/how-do-i-
exit-t...](https://stackoverflow.com/questions/11828270/how-do-i-exit-the-vim-
editor)

I don't think it's fair to ask every user to read the man pages, read a book,
take a class, or go through a tutorial on how to use vim. If most users can
figure out notepad.exe or TextEdit.app without reading a manual or taking a
class, I think it's fair to say vim loses the usability battle, regardless of
how powerful of a text editor it is.

I find most evangelists of tools have jumped from some feature anemic tool
(notepad.exe or notepad++) to a more powerful tool (like notepad++ or visual
studio, respectively) and decided "theres no way anything is better" then plug
their ears to hearing about better tools. Nothing could possibly beat the
amazing tool they use now!

JetBrains tools are less ubiquitous than vim, and sure take up more disk
space. But the usability and power, as far as I can tell as I am no vim
expert, far exceed that of vim. If I'm going to pick a daily-use tool, it's
not going to be the one so small it fits in the tiny memory of my router, I'm
going to pick the tool that with the most utility.

The original article should simply say "In many cases, vim and emacs are your
only two options. When you are forced into that corner, you better know at
least one of those two tools. You should learn vim because it's the (just
barely) easier to use of the two ubiquitous editors."

------
zwieback
I think if you never bring up a barebones Linux (e.g. embedded system or some
old HW) you might not really need it.

But being able to connect via serial port to some crappy stripped down Linux
and knowing vi is there is a good feeling and it asks nothing of you in
return.

------
clircle
I'm been an Emacs+Evil user for many years, but I would like to switch to
Vim-- mainly because I use Windows 10 most of the time now and Emacs can have
some input latency. But I'm old now and can't really imagine life without my
init.el.

------
seorphates
You should learn vim if you want to deal with systems. You can learn vim or
not if you don't.

lookback: vi, sh and unix have become your vim, bash and linux systems of
today. Now, while they have forward compatibility, of sorts, vi and sh, the
same cannot be said in reverse, as a rule. Modern bash folks have bent bourne
shell syntax into foreign looking contortions where bourne shell syntax is a)
performant and conformant, b)a lot simpler when simpler is better and c) is
why bash maintains posix.

I agree, learn basic vim. And bash. But not really to program with. It's more
of a burden than not for a million languages and formats.

------
grativo
One useful configuration was changing the command mode key to a single letter.
This way you did not have to switch back and forth between escape.
Additionally, for people who have hyperhydrosis, which drastically hinders
laptop touchpad usage, vim is really useful for navigation. As for vim itself,
it is perhaps more effective to use a modern text editor rather than Vim as it
is was a bit of a hassle to get it set up. Vim is very useful, and its good to
see more encouragement for it in modern software development.

------
zabzonk
It ain't that difficult. Back in the late 1980s/early 1990s, I worked for a
training company teaching C and C++. This was done on Unix boxes and our
clients were mostly VAX VMS and IBM people. The editor we used to write code
was vi (not vim). The clients had no prior experience of it, but by the end of
day one of the course they could write programs using it - not without a lot
of complaining, it must be admitted. Perhaps people were smarter back then?

------
fullstop
I use it because vi is everywhere.

The busybox implementation kinda sucks at times, but I can't complain given
that they've obviously focused on size.

~~~
commandlinefan
> vi is everywhere.

Although, surprisingly, most command-line interfaces and command-driven apps
(like redis client and psql) use emacs key bindings for command history.

~~~
joatmon-snoo
This isn't a deliberate choice though on their part, is it? Isn't it just a
consequence of everyone depending on readline and readline using emacs-style
key bindings?

~~~
duskwuff
Some Emacs-style bindings, like ^W (erase word) and ^U (erase line), are baked
into the UNIX tty discipline -- basic implementations of these bindings exist
within the kernel.

------
javier10e6
vim/vi is to linux embedded dev what a nail gun is to roofing or a Henckel
knife is too cooking. Don't show at work without it.

------
devchix
I find that most passionate vim advocates have spent a lot of time learning,
using, twiddling vim and the investment has paid off and now life is great. Is
that a point for vim or his persistence? I'm unpersuaded that I should learn
vim instead of $EDITOR, I just happened on vim first. Speaking as an
inveterate vim user.

------
nix0n
For anyone who has been inspired to try vi/vim:

To exit vi or vim, press Esc then type ":q" (without quotes) and hit enter.

If it warns you about not saving, try ":wq" to save and quit or ":q!" to quit
without saving.

If this is in the article video I apologize, but I did check and it's not in
the article text.

~~~
JadeNB
This vimmer is always inclined to laugh at tutorials for how to exit vim … but
then I remind myself that I still have to Google how to quit emacs whenever I
stumble into it.

------
2OEH8eoCRo0
I use vim because it's guaranteed to be installed. The version installed at
work is from 2004 but still.

------
AndrewOMartin
EX mode

How to get there? Press Q in normal mode.

What is it about? To punish you for trying to type while still in normal mode,
or for having fat fingers. An opportunity to type "visual" to go to Normal
mode.

------
brian_herman__
Larry Tesler would disagree.

[https://en.wikipedia.org/wiki/Larry_Tesler](https://en.wikipedia.org/wiki/Larry_Tesler)

------
adamnemecek
There are so many of these articles, why write another one?

~~~
f6v
_Mandatory GPT-3 comment_

~~~
oblio
Are you implying the article is auto-generated? Your comment is a bit vague...

------
ggm
Oh for a good (stress _good_ ) orgmode for vi(m)

------
wry_discontent
I moved from Vim to Emacs and definitely prefer it as a minimalist editor.
That said, I usually end up working w/ VS Code or Intellij

------
eddhead
Oh look, yet another Vim nerdgasm

------
Fred27
Learn Vim in 2020... because 2020 just can't get any worse.

