Response to Andrew Ray’s blog post:

This post will deal with a blog post made by a certain Andrew Ray who advises new developers to choose  Sublime Text in favor of Vim as their text editor of choice.
I disagree with that notion for various reasons that will become apparent as I go over his rant (making the TL; DR: He squandered potentially valid points by grotesquely exaggerating them at best and straight up bullshits out of his ass at worst (which is 90% of the article)), but could understand, since Vim really is quite different from pretty much every other text editor out there, but that uniqueness, which does come at a price of a learning curve and software setup, is actually the reason why it’s the best editor on this planet, and probably in the solar system, but our friend Andrew has a slightly different opinion regarding this*.

(*Aside from turning  a little schizophrenic in the end where he goes on about how  he will judge anyone who wouldn’t learn Vim since it’s needed for quite a few tasks Sublime Text cannot help with and so on.)

Anyway, go grab a cup of coffee and 3 days worth of provisions while I put on some rubber gloves, reach into that special dark place Andrew went to cook up that nice big pile of “dissenting opinions”, or bullshit, as we in the trade call it, and waste some time writing thousands of words on a blog post, that, after actually using Vim for a while, wouldn’t even need to be mulled over like I am about to.

Especially since I shouldn’t have any free time by virtue of using the evil Vim, the editor that never stops being work for the user, right? Indeed, but the bread line at the welfare office I conveniently live behind was shorter than usual today, so here I go:

“Vim: The Editor You Need To Read (At Least) Two Books On To Use Well”

Oh boy, that heading, what a whopper straight from the get go.

Vim is […] not going to make you type faster.

That is correct, it won’t make you type faster than you already can. Sublime Text, however will most likely indirectly make you type slower, or less often, depending on how much you use your mouse or touchpad, which both suck your fingers away from the delicious keys that can be typed, or even better, edited with. Anyway, insert mode is the worst mode for any editor, period. As Drew Neil likens it to painting, where the painter is very unlikely to keep the brush touching the canvas all the time, and might be surveying the scene instead, mixing paint, and so on.

The delicious godlike powers of Vim are pretty much all in its normal mode, where less than a handful of keystrokes can do amazing things. Not that Vim doesn’t have any insert mode chords, which also are amazing :h ins-special-keys, but the big kahuna is still normal mode and is what separates Vim from pretty much the rest and enables it to reign supreme, in my opinion.

Vim is not a more efficient editor for regular text editing

That is less correct, and it can be demonstrated, which will happen throughout my post.

For the first 1-2 years of your Vim usage you will be much less efficient than your current editor because of the odd yet lovable key bindings. After about 2 years you will be proficient.

“vimtutor”, the small training document/script that comes with Vim expects about 25 to 30 minutes for someone to complete it. It guides the user through the fundamentals of Vim by giving them small sets of problems, their solution and a little area to actually practice them. After finishing it, the user is generally able to:

• Navigate documents quickly:
  • Jump to lines directly using {line}G, which beats having to scroll there and a reason why even notepad.exe has a go-to-line shortcut. It also beats control + g/p for ST since ST opens a pop-up that requires enter to close while also being less comfortable than Vims solution since the control key is further down than shift.
  • Searching for things with /{searchterm} and n and N to go to the next and previous results.
    A clear winner over STs control + f and (shift) enter key shenanigans to jump to results, not to mention that STs search box needs to stay focused to work properly.
    (Also, Vims search term is stored in a register, as a bonus, to be used in other operations, all for free.)
• Edit text efficiently:
  •  Deleting  or copying a whole line with dd or yy beats any mouse usage and doesn’t require modifiers, like ctrl.
  • In insert mode, control + u easily beats STs control + K + backspace to delete from cursor to the beginning of the line, as does d^ or d0 in normal mode.
  • Shift i and shift a to insert in front of the line or after it, is, again not very easily beaten with a mouse or chords.
  • Operations, like (d)elete, (c)hange, (y)ank or (v)isually select on text objects like (w)ords, (p)aragraphs, (s)entences, quote pairs with their respective glyph, (t)ags and parentheses and brackets with their glyphs are matters of up to three keystrokes, depending on whether the user wants the action to be applied (i)nside, leaving the delimiters alone or (a)around to include them, or no modifier at all to make smaller scoped changes. Quote operations even jump the cursor to the next pair if it’s not inside one already. Example das, delete a sentence.
  • Even deleting single characters with x is awesome, especially in conjunction with p to paste it again,  xp, and you have swapped two characters.

And so on, there are more ways to navigate and edit text, but I like to stick to vimtutor for now , since that addresses that alleged “At least two books read over two years prerequisite” Mr. Ray. attributes to Vim. Yet, seeing how the things learned in these 30 minutes pretty much all beat STs counterparts (which, by the way, have about as much mnemonic value as Mr. Ray has honesty in his article), without plugins or scripts, I consider this point at least somewhat satisfactorily debunked, making the rest of that paragraph

Everyone talks about the steep learning curve but no one talks about what happens once you finally get hjkl in your brain for movement. The answer is months of frustration, followed by finally having a usable editor, followed by knowing some cool tricks that you use in 1% of your daily workflow.

Not worth to further comment on unless dealing with text like that only makes up 1% of your workflow, which I doubt.

What a great start for his article; let’s move on.

“Efficiency from Keeping your Fingers on the Home Row”

The argument that Vim is more efficient is dubious and untestable

I disagree, it is a simple comparison of how much work the user has to do to achieve some effect. In Vim, for example :23m. would move line 23 below the current one, all in one go and without moving your cursor. If ST can do the same with less, then we have successfully concluded a test that shows STs efficiency concerning line movement and we could repeat that for any desired editing action.

Reaching for a mouse may indeed slow you down, but developers are commonly on machines where the trackpad is a micro-hand movement away.

Where does he get that data from? The same place as everything so far, his pair of hairy cheeks with the puckered hole in the center, but let’s pretend it’s true, but even then, unless you’re doing it with your thumb, your fingers will leave the home row.

Most novice programmers can click on a character on screen faster than an expert Vimmer can type 20jFp; or LkEEE or /word<cr> or any other nasty way

Most likely true, but the actual subject doesn’t need  to be called a novice programmer, but a novice Vim user in general, since Vim isn’t just for coding, even if it’s the main focus, I’d say.

Anyway, Vim has had mouse (and arrow key) support since pretty much forever, making this point already a bit weak, but using the mouse really isn’t all that good, even for nasty stuff like that, especially with relative line numbers enabled to make line jumps a no brainer.

Let’s actually take that example from up there, as needlessly complicated he engineered it to be, and compare it with the mouse.
20j to move down 20 lines, F to search backwards in the line for the letter p and ; for  p’s next backward direction occurrence in that line.

Very nasty, yes, but also very clear, pin point precise, in the case of the F motion generalized (meaning it doesn’t matter how far the occurrences are apart, Vim will jump to them perfectly) and  thus macroable.
The mouse is a little bit more tricky to predict when it comes to required effort. Is it close to the target, fine, what if it’s in some far away corner? Then the user needs to reach and drag further, having to land on the actual target (which some touch-pads might make trickier than others, same with their sensitivity, requiring more rubs to get to the spot ) and then put the fingers back on the keys to continue typing.

Sounds less awful? Perhaps you might think so, until the user wants to macro something, or needs to go to yet another p in the line. If they did then they would need to use the mouse for another grab-drag-n-click ritual whereas  Vim would only require another semicolon and they’d get their cursor on that third p, as desired.

Also, Vim automatically creates bookmarks as well as jump table entries, for those `few’ occasions where the user might want to go back to whence they came.  ” (that’s 2 apostrophes) or “ (2 backticks) would jump back to the last location and upon repeat would jump to the next again, either only to the line with the apostrophes or line and column with backticks, since that’s how marks work, apostrophe mark goes to line of mark, backtick mark goes to line and column. gi would immediately jump to where the user last stopped inserting and enable them to continue inserting there, control i and control o move through the jumplist,  and so on. More examples will follow as we go along.

The point of a mouse is to make arbitrary on screen jumps efficient, and it’s very good at doing that. Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter.

Actually, the mouse isn’t good at that at all, a touch screen would be, but not a mouse, a mouse is awesome at generating changes in x-y coordinates, a reason why it’s so much better for things like drawing than a keyboard would be. Still, the type of program we are discussing does not benefit very much from these deltas but  only the start and end points of a motion and Vim has a very predictable and consistently speedy way of teleporting the cursor around in such a way, which, in my opinion, beats the mouse easily.

This is even more true for repetitive tasks that can benefit from the awesome macro-ability Vim gives text navigation. Still, even for simple things like moving to or between paragraphs, parentheses or tags and so forth, Vim usually has a one to three character long sequence to jump to these landmarks directly. No need to aim, no need to use a mouse, just go there directly.

For illustration, here is a list of delete commands, grouped from small to big
objects, straight from the horse’s mouth, Vim’s documentation:
diw    delete inner word
daw    delete a word
diW    delete inner WORD
daW    delete a WORD
dd   delete one line
dis    delete inner sentence
das    delete a sentence
dib    delete inner ‘(‘ ‘)’ block
dab    delete a ‘(‘ ‘)’ block
dip    delete inner paragraph
dap    delete a paragraph
diB    delete inner ‘{‘ ‘}’ block
daB    delete a ‘{‘ ‘}’ block

And those things don’t require the user to aim the mouse, just to have the user aware where they are.
cib or ci( anywhere in a pair of parentheses and the content is prepared for change, no need to aim, no need to drag the cursor, just three characters and your goal is reached. Can you beat that with a mouse? Well, you’re pretty good then, as well as more harshly subjected to RSI for having to move your arms and hands around that much. Check out IOGraphica, it’s a mouse usage visualizer, you might be surprised at the distance you make your pointer travel during computer usage.

The mouse argument is trivial. The real problem lies deeper.

In this case, possibly a deep state of delusion on Andrews part.
(That, and general hostility toward the keyboard by operating systems line Windows. Mac OS not so much, their users get Emacs bindings for free and Linux based OSes have the sky as the limit in  general, the sky and drivers, but that’s another story.)

Let’s move on!

“Plugins and Extensibility 1: Management”

I will gloss over this, since, while the past was indeed a dark age, it also really is the past now. Vundle has matured and now has a  `few’, aka about four thousand, plugins indexed. Not to mention the user can add their own repos which Vundle integrates neatly, along with selective loading, updating, cleaning and all that good stuff.

This is all especially scary because Vim out of the box is awful. I can’t stress how bad of an editor vanilla Vim is.

Completely subjective, and also false, as stated above since even the stuff learned in vimtutor kicks plenty of (Sublime Text ) ass and vanilla Vim has syntax, formatting and indentation support for over five hundred filetypes. It’s also available as a terminal version where ST falls completely flat, and so on, there will be more to talk about as we go on. Also, he acts like ST doesn’t benefit from plugins itself but it ships with a selection of them OoTB so those don’t really count I guess. Maybe someone will make a `Vim-complete’ package with the over 4400 plugins  the website indexes for that extra rich vanilla flavor Andrew craves, only not, since there would be collisions (which is true), but we will focus on those a bit further down.

“Plugins and Extensibility 2: Ecosystem”

Vim Scripts. Barf. Think CPAN with less formatting, fewer features, and more ads.

While the site certainly lacks a modern look it’s perfectly functional and does everything it needs, also Vundle, as linked above has many of the plugins indexed and scripts are getting githubbed, too.
It’s a big collection so it takes a bit of time, but, while there are still scripts that aren’t indexed by Vundle or on githubs, yet, they still actually exist and do not have to be reinvented in Python, which all the poor ST plugin authors now have to do. Paying 70 bucks to port over Zencoding/Emmet in Python that does nothing better than Vims version sounds like a deal to me, too, especially should Python break between versions and so on, delicious code duplication and maintenance. Do you guys at least get paid for digging yourself into that walled garden? I sure hope so, since your work is used to advertize and sell ST.

Anyway, moving on:

“Plugins and Extensibility 3: Vimscript”

Expect some agreement in this section.

Ah, Vimscript. It’s bad.

True. It’s shit (really, it is) , but so is PHP, or Java, or VB or objective C, etc,  not difficult to find hate mail for these, but also not difficult to see the myriad of big things done with them.

And yet we’re stuck with it

Not as true, Vim can be scripted in Perl and Python easily, for example but yes, interfaces are made in Vimscript.

The main problem with Vimscript is that it’s not another language. No one knows it. Most experienced Vimmers I know don’t know any Vimscript.

I don’t know how much of an argument that is, since Vimscript was apparently known well enough to have given us all those thousands of plugins , and seeing how ex commands (and normal key sequences ) are actual building blocks for Vimscript , merely using the editor teaches the user that part of the API, passively, as a bonus. Case in point: Andrews own .vimrc, which contains more vimscript than my own. Go fancy that.

The documentation on it is terrible, and made much worse by the fact that it’s near impossible to look up help on it.

Well, the documentation certainly is extensive, and thus can appear overwhelming, but Vim is one of the most thoroughly documented pieces of software I can think of, if the user wants help on a topic, it’s there, 99 times out of 98, for the most part.

Let’s say you want to write a function. Ok. let’s look up the help for function. :help function. Oh good, this isn’t what we want at all.

I have to agree there. Granted, the help about defining functions is two paragraphs below, but the index tag is E124, which isn’t exactly intuitive.
With default keybinds, pressing F1 or using :help, however, would give anyone a help index and the bookmarks leading to Vim customization documents would be found in the first third of the file, not too hidden, imho.

all of Vim’s help is equally poorly accessible

That, however, is not true. :helpgrep , for example is pretty nifty and makes slogging through that huge amount of help easier. Have a video about it. Anyway, as with the majority of things, Vims help system easily beats Sublime Texts documentation by far, seeing how the first hit for “Sublime Text help” on Google links to a deprecated version of it, which then leads to some other inofficial docs, which need a browser session and has such super advanced features like a primitive searchbox.
(And, of course, the tone used in these docs is similar to Mr. Rays. That is, childish slander laced with delusion of grandeur.)

Also, again, Vimscript gets taught to the user on the sideline by virtue of exposing the majority of the API through general usage, plus the platform, the editor, is FOSS, no dictator who might just change things around depending on the waft of money, and so on, which would make me wary to lay all my eggs into one basket, especially if I’d be a plugin author.

Anyway, moving on.

“Plugins and Extensibility 4: Collisions”

This is a big one. Vim is missing an incredible amount of core functionality for modern editing. Things like ctag integration, project management, project browsing, (yes I know about :Sex), and many other basic things, are completely absent in Vim. This is by design

Yet another bullshit paragraph, or maybe Andrew has gone to some place where the latest version of Vim suddenly doesn’t automatically read and use tagfiles anymore and also lacks Session support (which is what a project is). Not that you’d actually need the latest version for that, but we are taking ourselves very seriously here.

Ok, we need a project-like file browser. Let’s get NERDTree, most people know about that. But wait, NERDTree keeps leaving shitty things open when I close buffers.

Like what? That exercise is up to the reader, I suppose.

Most people don’t know about NERDTree tabs, but NERDTree is incomplete without it

Again, where do those statistics come from? “Most people”. Are we counting the entire earths population or something?  Well, if we do then we have a lot of people who don’t know about things, including the entirety of Sublime Text. Also, NERDTree without tabs is not incomplete for users who don’t use tabs, like me, so why would I want something I don’t want bunched into something I do want?

And ugh, it looks nasty because of Vim’s monospace font restriction for the entire UI (more on that later). But I guess that’s not so bad…

Well, that’s personal taste, but it’s legible and neatly ordered, no aberrations.

Now we need to find files. Let’s use Vimgrep! Oh wait, that sucks.

Again, that’s subjective, especially if it does its job, which it does, but it really is rather basic, so let’s move on.

Ok let’s get Command-T. Oh wait that’s incredibly slow and clunky and looks jenky

And yet another benchmark result without any data to back it up and some more issues of personal taste.

Oh, there’s CtrlP this is much nicer! Except, wait it doesn’t actually do correct fuzzy searching

Unless  control + r is pressed  to toggle regex search mode, which is noted on the top level readme of the git repo and creates the exact result the issue was covering, and to top it all off, it didn’t even take a year to show the result in addition of the plugin providing a control variable to start in regex mode by default. Could I be using a different Vim than Mr. Ray where things aren’t as awful as the howler monkeys try to make it seem? Perhaps.

Finding the right Vim plugins is like being in an exclusive club. It gets better around year 2 of your journey, then worse around year 3, then…

Anyway, he doesn’t dwell long on his game of pointing at arbitrary plugin issues, which Sublime Text in its perfection obviously has not, and instead spouts some more unfounded shit and thus we can move on to enjoy more bullshit.

Back to collisions, there are many plugins which touch the same functionality, because default Vim offers so little.

Actually seeing how it’s Vimscript that does the most part for the majority of plugins, Vim offers the building blocks for that functionality intrinsically, if we want to get technical. Let’s humor him and go on, instead. Vim has so many plugins that do similar things because the editor is about two decades old, has been ported to a myriad of systems used by people from a plethora of different backgrounds with different needs. Not saying that that code duplication should be excused by that, but it explains it very well. Anyway ST has both an advantage and a disadvantage here. The advantage is that it is a relatively young editor with a smaller user-base, mostly Web Devs, it seems, don’t have the statistics but I’d be surprised if they weren’t the biggest chunk of the userbase. This makes it easier to start fresh and focus better whereas Vim has several thousand of plugins available, making the process less straightforward. The disadvantage, again, however is the fact that while Vim has a few bad eggs ST users need to build up a library that can compare to Vims counterpart on a level that would actually warrant nestling into that proprietary walled garden. Emmet, for example. I don’t see any advantage in STs version over Vims, especially since Vim has the superior interface, but more to that later.

Anyway, I’m gonna grant Andrew the point about there being plugins that overlap in some areas, that can be a pain but on the upside you have a much bigger pool of plugins available in general.

What I won’t grant him, however:

And all of these plugins are gauranteed to fuck up Vim’s default, already complex and confusing auto completion!

That’s not true, or, at least, I have not come across a plugin that  destroys the functionality of the built-in system. Also, complex? True, but also powerful and easy to access, control and up to 2 keys will give you tag completion, word completion, line completion, file path completion and so on, which isn’t bad for something horrible vanilla Vim comes with, in my opinion, but let’s move on, because the next block is another pile of bullshit again.

Your search plugin will collide with your auto complete plugin.

No, it won’t, unless you specifically set yourself up for it and that scenario is not exclusive to Vim. It is perfectly possible to write two ST plugins that would interfere with one another, but of course that would not be the fault of the editor, but the user fault for not reading up on what the plugins actually do. Well, unless the user is a Vim user and we have Andrew here to pass judgement, then it clearly is the editor which is flawed.

Your syntax plugin will collide with your dictionary. What does a collision mean? It means randomly Vim will spit out 500 lines of highlighted red text at you, but just for a second, just to let you know you fucked something up.

Again, more dishonest bullshit, and to follow up, some more of the same.

You’ll see a huge red flash of text at startup that you can’t read, copy, nor save, and it goes away after 2 seconds, and suddenly your editor is slow a dog and you have to go plugin witch hunting.

I’m surprised he didn’t also add in some actual wounding of the user and Vim violating their dog and whatnot, but anyway

:messages would print these messages.

Moving on.

“Vim Is Bad By Design™ 1: Oooooollllld”

Oh boy, the next few paragraphs are going to be the bullshit cherry on the crap cake, and this is the perfect starting point, but the main deal is gonna happen in the GUI section, and so on, but let’s not miss out on more delicious bullshit.

Everyone remaps Leader from backslash to comma.

Citation needed, but again, let’s humor him.

Backslash was chosen because it used to be convenient to type, in like 1943 or something. Now it’s in an awkward place on most modern keyboards. The remap overwrites comma, which is a very useful keystroke

Ah, 1943 I’m surprised we didn’t go back further, but it’s true, backslash, along with escape were closer to the home row back in the days where the world still used terminals for the most part.
Anyway, I think Andrew is exaggerating the importance of comma a bit. Comma goes to the previous match that f or t are looking for, and seeing how F and T search backward instead of forward we can either use these or we could map comma to backslash since F and T have the functionality intrinsically, no need to reach for backslash that often, and the shift key isn’t  bad, especially since it still beats STs search shortcuts, even if the backslash were used.

Do you know what the suggested way to work well with multiple files in Vim is? It’s the arglist.

Yeah, if the user wants to open Vim and load multiple (globbed) files at startup, or at runtime (though that is less straightforward as the command for that is :next {list of files}) in one go, almost as if this list of files were a list of arguments passed to a function or program, but that’s not the whole deal, it’s actually a pretty useful thing, for refactoring a certain set of files without affecting others.

Most of my experienced Vim friends don’t use the arglist nor know what it is. It’s a clunky system for populating a special internal list of Vim with multiple files.

Actually, as hinted at above,  it’s a system that acts as a more stable subset of the buffer list. The contents of the buffer list can change often, and sometimes without you realizing it. Whereas the arglist will only change its contents when you give an explicit instruction for it to do so and there are special commands that only work on the arglist, so you can load your set of files you want changed and only have Vim affect those, even if you have 1000 other files in the buffer list, they will not be touched.

It can actually be quite handy at times

Indeed, for working with a set of files the user wants to keep contained and the user can change the list at any point in any way they choose, either manually or even have a script feed Vim a set of files, seamlessly and concisely, not something ST is good at, at all.

but you may only use it three times in your whole Vim career.

And that’s true. If you use it more than three times then your punishment will be shilling proprietary text editors on the internet. Seriously though, the arglist is made for a good purpose, a purpose that the user will praise Vim for, and would curse Mr. Ray who slandered it. The same Andrew Ray who claims that he loves feature richness, which vanilla vim apparently lacks so vehemently, until right now where Vim has too many features, so, err…well.
Well, let’s just say Vim having features is bad, especially when it’s a feature Sublime doesn’t have, right, Andrew? In fact, I’m surprised he hates the feature so much, seeing how there is a German word spelled just like it and which translates to malice, deceitfulness, fraud, etc. all attributes Andrew has in spades, if we take his little blog post as any clue.

Anyway, here are some vimcast episodes showcasing it. Here, here and here.

“Vim Is Bad By Design™ 2: GUI”

We will be having some fun and hopefully some eye opening in this paragraph and in the case of one point it’s even not only a ST issue, but also other text editors and IDEs.

Vim is designed to run in a terminal. That’s why it’s explicitly linked to only monospaced font for the GUI. A terminal can’t draw a UI. I get it, we have to draw things with blocks and underscores and what have you. Ok, I’m fine with that.

Good, cause that is a good thing™.

I’m on a server, I’m editing a file probably as a hotfix for something, I don’t need a beautiful editor to do that. I just need to edit text.

Vim is plenty beautiful, though, but more about that soon. I’m more interested in the very last bit, and so should anyone, editing text and Vim (in my humble opinion) has the best GUI for that (or TUI, rather, unless we’re talking about gVim with its menus and toolbars, etc.)  as we will see, soon.

But Vim is supposed to be an editor that you don’t always have to use on a server.

That’s true.

Here in the future, we have these things called GUIs. They’re super nice!

They’re not nice for everything.

They look good, are usable, and give useful visual metaphors for things.

Yeah, but not always, and ST actually has one of the most awful GUI widgets invented recently, the minimap,  which I will talk about soon.

Do you know what benefit MacVim has over terminal Vim, visually? It has styled tabs. That’s all we get, and that’s all we’ll ever get.

He seems to be forgetting the menu bar that many plugins and vanilla Vim things support, and contain all sorts of functionality like:

Standard file operations, choosing font sizes, the file type of a file, word wrapping, diffing tools, dialog driven search and replace, color scheme setting, keymaps for input, how lines are numbered, tabulation settings, spell checks, ctags support, jumping to tags, makefile support, quickfix window (the thing that shows compiler errors and jumps to them etc. ) actions, code folding, compiler settings for languages, hex editing, buffer actions, syntax options, window actions and whatever menu items the plugins might spawn (like all the LaTeX structures and stuff Vim-latex puts in there). Oh, and styled tabs…and a toolbar, but let’s move on.

Text cannot nor ever will have padding for readability.

Actually, if he means space between lines, then that can be set with set linespace={integer}, provided the GUI version of Vim is used.

You cannot show more than one font size on the screen at once.

That is true, unless I am missing something, but it’s fine, since anything that isn’t a  text buffer is usually only used briefly in Vim, since anything but a text buffer  is a “distraction”, as Jon Skinner, author of Sublime Text calls it, and I agree, and because of that he gives ST users a “Distraction Free Mode” that will, ironically, or rather sensibly, make ST look more like evil, ugly Vim than ST itself.

(ST is on the left, by the way.)

Yep, not Fullscreen mode or anything else, but Distraction Free mode, language matters and couldn’t be more accurate here, Skinner definitely hit the nail on the head with that one .

If you want to zoom in your buffer text, you also zoom in your file browser.

Again, file browsers should only be used when there is a need to browse files. Is that confusing? How would one keep everything in mind? Well, Vim (and ST as well, actually) has all sorts of listing or direct/fuzzy selection for those kind of things. No need to have a big ass pane on your screen all the time. You want to switch to some buffer? Type in a partial name to narrow down a list and you’re there, back in the game without any distractions.

And your command line. And your status line. If you want to use a more readable, non-monospaced font to style a dialog, then you’re going to be very sad.

See above. It’s all good , but let’s move on, I have more things to say about “fancy” features that will actually drain your attention, time and work down into them.

We will never have a minimap

And we have arrived! The minimap. Hailed by many, so much that copies of it can be found elsewhere now, even Emacs has an implementation of it, poor guys.

(beautiful feature).

Things could not be any more wrong. It is an evil, insidious device, I know, that’s saying something since it’s an unliving product of code, but it is evil and we shall now reflect upon it a little. All without Vim, just the minimap itself and what it does to the people, because it’s that bad. It transcends editor wars.

The thing is, the minimap trains the user to do things through it they could have done directly and without having to memorize their code, which the minimap requires them to do unless they are fine with only having a strip of illegible colored splotches describing something that looks like seismic spikes. This is quite the irony since Andrew will claim “*To code in Vim, you have to keep Vim in your head just as much as the code that you’re editing. You have to constantly think about what you’re doing.” a few paragraphs down.

I’m sure I don’t have to upload a screenshot of a minimap on its own to ask you whether you can tell me anything about the code apart from how many indentation levels it has, you wouldn’t be able to say much more.

In the case of  a breakpoint list directly, for example, you would see not only see all the breakpoints but also where they are  in the code, etc.

Sure, the minimap in MSVS™ would show a breakpoint symbol on each occurrence, but, unless you have mentally mapped your code to the minimap, you’d have to take your hand off your keys click the minimap to see what it’s all about, again. Well, one Visual Studio™ user I talked about this claimed that the minimap is still useful since it enables the user to see  things `at a glance’ anyway, but sadly the thread we were arguing in got deleted before I could tell him why that’s bullshit and how it would be an exercise about refreshing code to minimap mappings again at most.

Same with search matches. You get your highlighted splotches on it, but then what? Indeed, you need to click around again instead of showing a pane that lists all search results directly, with context. This principle can be applied to any function a user might like the minimap for, they are getting punked, especially in ST which has (and I mean it) that excellent Fuzzy Go To Stuff functionality or in Vim that has things like :g/term/p, a global regex print, or “grep” for the people who didn’t know where the term comes from. The /p is the default and doesn’t have to be supplied and a # would print line numbers, as well. Good stuff!

Anyway, the minimap is a user trap for every text editor that implements it and if the user sits down and spends some time considering the shortcuts their editor might offer to jump to breakpoints directly, listing them, listing search matches, jumping to code landmarks directly and so on, then, unless they are in a keyboard hostile environment (and often even then), they would most likely come to the same conclusion. A trap. An insidious bauble that makes the user think they are doing something modern and innovative while they’re actually suckered into doing things through a backwards ass proxy.

But no, Vim does not have a minimap, Andrew is right about that, but at that point you might be okay with it, perhaps.

We will never have multiple cursors.

Wrong again, Mr. Ray. Lookie here and, as a little bonus, they’re even better than Sublimes. Check out the video if you like. They have regex support and other neat things, and they’re quickly set, as can be seen in the clip. (Also, notice the math he’s doing inline! The benefit of having an editor that integrates with the shell seamlessly. No plugin used for that, just Vim and his OS.)

We will never have a pretty fuzzy file finder that pops up in a reasonable location.

Well, FuzzyFinder pops up at the top left, but, since it uses the font your text uses it will most likely be considered ugly as sin, especially since it doesn’t sport any fancy borders, unlike CtrlP, which has some frills, but also just text, which again, can be considered utterly visually unbearable.

We can’t place dialogs in arbitrary places for usability.

Some more falseness. Vims windows/dialogs, which are the host for all those filemanagers and so on, can be arranged like in a tiling window manager, which makes sense unless you want your NERDTree pane floating around in space somewhere during those moments you’re actually interested in seeing it, then that would indeed be impossible, but other than that, they’re a lot more mobile than Andrew might want to make us believe.

Honestly, Vim’s UI gets old. Sure, I’m mainly editing text in here, but I’m here for most of my work day. I want it to look and feel good.

Well, unsurprisingly, Andrew and I have some different tastes here, since I consider Vim very elegant both look and feel wise. I can just sit down and hack away. I flick my fingers and text gets created, torn apart, reshaped. Effortlessly. No distractions, just me, my target and the things I will into existence, straight from my fingertips into the file. No mouse, no distractions . Just fun. I love it and any many other applications have plugins or native features that offer Vi/Vim like functionality, giving me a globally unified interface for all the things I do. I really do love that, being able to browse the web, check mail, play music, read PDFs, use the shell and even play some games. I cannot think of something that could feel better, especially since said features pretty much always improve the program greatly. Check out pentadactyl or vimperator, read the user reviews, which are overwhelmingly positive. Some go as far to list these add-ons as the sole reason why they’re using Firefox, me included (well, on top the competition either being spyware or just plain old things I don’t like.).

But I rant, let’s move on.

“Vim is Oddly Bad at Indenting”

I don’t think so, and …

<div>
<p>
<span>foo</span>
</p>
</div>

indented to

<div>
    <p>
    <span>foo</span>
    </p>
</div>

For me, which I am okay with. ST also indents the span. The usefulness of that is lost on me personally, but I neither love a minimap where every spike of indentation helps mapping the code to the map nor am I a web dev. If you are, however, and would want spans to be indented like that out of the box as well, then you would have to either set some options or edit/download the html syntax file, or just use ZenCoding/Emmet, which does everything correctly.

For some strange reason Vim is bad at most indenting. Forget about having your javascript indenting work right. After messing with cindent and smarttab and shiftwidth you’ll turn to plugins, you’ll find javascript.vim but that doesn’t quite work and a forked version but no that has problems too, and someone else has something named the same thing but it’s different? I don’t really know why it’s such a mess and it’s my fault for not investigating it myself, but why the hell do I have to configure my editor to indent common languages? You should know already, Vim.

Despite agreeing with Vim indenting things in ways that might not be to the preference to some particular user, I still cannot let this stand unconditionally. Why? Because it’s wrong.
Cindent, for example governs the indentation for the C language and the tab settings merely govern how tabstops  are treated by the editor and how many units of whitespace they are worth. The rest of this paragraph is just personal opinion, which mine, being okay with it, falls under as well. I recommend building your own.

After four years of Vim use, 700 hand written lines in my .vimrc, and 45 plugins, I cannot in good faith recommend that someone start the Vim journey.

Alright, home stretch.

I want my coworker to edit text and get up to speed quickly. Is telling them to use Vim the answer? It will just slow them down for months. This is not pragmatic to the technology industry. Maybe it will pay off in the long run. Maybe I just don’t want to deal with their Vim journey.

This sounds like a good argument at first, and I would agree, too but I also disagree in a way because it’s not really a good argument. Why learn how to drive, when walking or riding a bicycle with training wheels  is so easy. Both get a person to a location and having to go to driving school just sucks away time the person could have spent walking. This is not pragmatic. Will it pay off in the long run? Maybe I just don’t want to deal with mock testing them on question sheets.

Still, he’s right. I wouldn’t want anyone to learn Vim during a time critical moment, as well, just as I wouldn’t advise someone who works in a field that requires typing to switch from their native layout to something like colemak, but:

I would still tell the typist about it, as an option that will save finger travel time and increase comfort, or, in the case of someone who transcribes things, I’d even go so far as to recommend plover, a software that enables the user to use their standard keyboard as a stenotype one. Have a video about that one. A fine video, too, since the typist makes a mistake and produces some horrible garbage at one point. Now, I don’t know about Andrew, but if I had to type lots and lots of text per day, I’d still use plover despite that blunder. Why? Because it apparently enables 200wpm on average for a somewhat proficient typist without having them to rip through their finger tendons and thus allows them to not lose steam after a minute or so, like a conventional input method might.

Still, not during work hours, please. We do want some shit gettin’ done, after all. In my own time, however? Well, I would at least consider it, but then again: I am a lazy bastard and thus appreciate anything that cuts down the amount of work I need to do, while multiplying the results I get, like Vim does for my text editing needs, Pentadactyl for my browsing needs, mutt for my email ones, and so on. All of them not exactly standard tools, like vanilla browsing with mostly clicks and handling email in a client like Thunderbird, but I love all of those things and, unless something better comes along, wouldn’t trade them for the world, and they all, coincidentally, have some vim elements and tie in with it. Go figure!

Look kid, I love you and all, but just use Sublime Text. Despite the fact that I moved writing this post into Vim because I couldn’t stand to do it in a textarea, even though I’m mainly just typing text. I missed my Vim movements too much. Despite the fact that I will probably never stop using Vim.

You’re going to have to know Vim. You’re going to be useless in the technology world if you can’t edit a file remotely, which will you will be in a terminal for, and which you will be using Vim for. You won’t be able to live without set -o vi on the command line to get Vi bindings in bash, and I will judge you forever until you actually use it…

I don’t need to comment much on these. Yeah, go and don’t learn Vim, cause it’s so bad, postpone it as long as you can, but you’ll be useless without it, which isn’t true. You could also learn Emacs, or Nano, or whatever you like, Vim is just the best choice overall, in my opinion.

But Sublime has things Vim can never have.

Yeah, like: a price tag, bad multi platform support, keybinds that can only be applied to itself and be found elsewhere, bad integration into other IDEs, not being a de-facto standard tool on *nixen, lack of modes, awful shell integration, etc.

It’s the new hotness and has a more active community than Vim does.

That’s subjective, but also plausible, since they need to make up so much for Mr. Skinner, porting all those plugins over and even writing documentation.

You’re lucky to see a Vim plugin that has been updated in the last year

Syntastic, Powerline, Vundle, NERDcommenter, NERDTree, Zencoding/Emmet, delimitMate and so friggin on. Lucky me! All useful plugins, all active, and the plugins that are not as active might simply just work, or have been deprecated by something else. Note: That isn’t exclusive to Vim, again, any tool big and used enough can become victim to that.

Vim is a lifelong journey.

Oh. He linked to a site that indexes some tips and tricks, some recipes, so to speak, to cook something nice with Vim bits, and as overwhelming this list seems to be, so would linking to a site like allrecipes.com or similar. Oh my god!
Our relatively tiny set of available ingredients permute to this many things?!
Cooking clearly is harmful and a life long journey that will just sap all your free time. Awful! If we take just a subset, of cooking, though, then things become more manageable and even simple things like good old grandmas cabbage soup with hearty sausage in it, will beat any fast food restaurant both price wise and volume wise. A big pot of that stuff can feed a man several days. Mh mh mh, and  just like reducing cooking to a subset like that, the author of Vim, Bram Moolenaar himself, at the end of his “Seven habits of effective text editing” states:

“Learning to drive a car takes effort. Is that a reason to keep driving your bicycle? No, you realize you need to invest time to learn a skill. Text editing isn’t different. You need to learn new commands and turn them into a habit.
On the other hand, you should not try to learn every command an editor offers. That would be a complete waste of time. Most people only need to learn 10 to 20 percent of the commands for their work. But it’s a different set of commands for everybody.”

And it’s true, it’s not required, or makes much sense to learn everything, and, as stated way above, even the vimtutor bits would enable basic text editing that no other editor can compete with.

Even now I want to convert this text, which I wrote in Vim at 80 columns wide, to non-fixed width text, and I’m going to go search for how to do it. I’m probably going to learn something in the process. At year 4 of Vimming.

Why he wrote the text in 80 columns to begin with is a mystery to me. Lines wrap automatically in case he typed this article in the terminal at that kind of screen width, or can be scrolled if wrapping is off, etc. So the most likely scenario, unless he really is a bit special in the head was him probably not writing it in fixed width at all, and just uses it as an argument to shoehorn his last  overblown example into the article and I’ll explain why that would make sense, too.

(oh, :set tw=10000 | norm gqie, with textobj-entire, duh)

One of his commits to his blog changed this line into what it is as quoted here, to make it look more ridiculous by virtue of requiring the entire-file text object.
Not that he didn’t already do a good job at making that sequence as needlessly contrived as possible.
here a shorter, more sensible version: :se tw=0 enter-key gggqG. 14 characters versus 26. He must have read the manual on textwidth, in order to know its abbreviated form and thus should have known that instead of 10000 a simple 0 would have disable it. He also knew that he would need to reformat the text to the new width, which is done in normal mode, as his norm ex command usage signifies. It doesn’t make any sense to tie those together that way, at least not as an argument against Vim. Just as it wouldn’t be as much of an argument to say something like “90s first person shooter X sucks because to shoot I need to open the console and type player->weapon->fire()” while having that functionality bound on a mouse button. I get it though, he’s trying to make a point. Even his experienced self, after 50 years of Vim usage, still isn’t ready to use the editor in a worthwhile way and neither would you!

Closing words:

So, there we have it. We’re at the end, for now, finally!

I probably could have put some things better, add more things here and there and use better grammar, and I will edit things in accordingly, but I still hope that there were enough side infos/trivia to make this way-too-long article at least somewhat worthwhile.

With all that said and done, do I recommend Vim? Absolutely.

Do I think it’s flawless and needs no time investment whatsoever? Nope. Vim isn’t perfect, it has issues. Vimscript is clunky and stupid and choosing plugins can be a hassle, indeed (though not as crippling as some people might say). It also needs some settling in by virtue of having modes and non-standard (but they should be) keyboard shortcuts, but so does Sublime Text and STs aren’t even found anywhere else, unless ST has adopted them from somewhere else.

I’m also not anyone’s mommy (though I might be their daddy, depending on who their mommy is) and I won’t, mostly because I can’t, make anyone choose one editor over the other. I merely am of the opinion that Vim is the greatest text editor ever conceived  and I strongly believe that Andrew Ray here is everything but a good argument for either editor. He seems to be an angry, whiny kid without patience or integrity and thus should be laughed out of the room, nine times out of eight should he try to talk about text editing again.

Anyway, even with shortcomings like that, I do think that Vim is the tool that has the biggest potential to become your most tightly knit mind extension when it comes to text editing.
It is Industry proven, refined for decades and available for pretty much all platforms (even my router has custom firmware, Freetz, that allows Vim to run on it).
It is free and open source software, making it available to work on for anyone.
It has plugins for pretty much anything as well as having vanilla features that do pretty much everything, albeit sometimes less sexily, like :e **/dir/file.foo, for a somewhat `fuzzy’ search for file.foo in dir, etc, kinda yuck, but it works.
It has an amazing interface that works with modes/modality and focuses on, instead of working around them, and that’s useful, since everything has modes, even Sublime Text.
(You search for text? Term goes into a special box, not the buffer anymore, you are, by all means, in STs search mode), and by virtue of this kind of approach gives the user editing functionality that is invoked in such a concise, yet powerful way, that the only way to find it in other software is by adopting Vims way of doing things.

So yeah, Vim has shortcomings, but the longer you plan on being someone who edits text in any way, the more I would recommend Vim despite them.
No matter the size of your needs, big or small, Vim will help you tackle them with ease and grace, but only if one sits down a little bit and learns its language.
Takes time? You bet. Years? Nope, though there is always the chance that the user learns something new and relevant they didn’t know of over time, as it is with many things in life.

And with that said, I’ll leave some Vim resources before I sign off.

Overviews, opinions of other users and general tutorials:

The Vim learning curve is a myth.
Switching from Sublime Text 2 to Vim.
Vim – precision editing at the speed of thought
Welcome to Vim
(part of http://www.derekwyatt.org/vim/vim-tutorial-videos/vim-novice-tutorial-videos/ )
http://vimcasts.org/episodes/archive

And the vim setup I am using and maintain.
By the way, I have forked his blog for posterity and in case case he gets all whiny and defensive.
Hey, okay. I’m petty. What’s he gonna go about it? Surely it won’t be not writing dishonest blog posts about Sublime Text being even remotely better than Vim any time soon.

ZZ

---