An article by Andrew Ray that no longer exists. Used to live at http://delvarworld.github.io/

just-use-sublime

  
  <header>
      <h1 class="entry-title">Just Use Sublime Text</h1>
      <p class="meta">
<time datetime="2013-03-16T19:06:00-07:00" pubdate="" data-updated="true">Mar 16<span>th</span>, 2013</time>
      </p>
  </header>


<div class="entry-content"><p>I originally wrote this as a response to “Sublime Text 2 vs Vim” <a href="/web/20130601181333/http://www.reddit.com/r/webdev/comments/19lobl/serious_discussion_sublime_text_2_versus_Vim_on/">on
reddit</a>,
but it was too long to post. I blogged instead.</p>

<p><em>TL;DR I cannot in good faith recommend Vim to a new developer, even though I
use it.</em></p>

<h2>Vim: The Editor You Need To Read (At Least) Two Books On To Use Well</h2>

<p>Vim is <strong>not a more efficient editor for regular text editing</strong>. It’s not going
to make you type faster. 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.</p>

<p>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.</p>

<!-- more -->


<h2>Efficiency from Keeping your Fingers on the Home Row</h2>

<p>The argument that <strong>Vim is more efficient is dubious and untestable</strong>. Reaching
for a mouse may indeed slow you down, but developers are commonly on machines
where <strong>the trackpad is a micro-hand movement away</strong>. Most novice programmers can
click on a character on screen faster than an expert Vimmer can type <code>20jFp;</code>
or <code>LkEEE</code> or <code>/word&lt;cr&gt;</code> or any other nasty way Vimmers have to use because of
our archaic, ingrained keystrokes.</p>

<p><strong>The point of a mouse is to make arbitrary on screen jumps efficient</strong>, 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.</p>

<p>The mouse argument is trivial. The real problem lies deeper.</p>

<h2>Plugins and Extensibility 1: Management</h2>

<p>The Vim plugin community has some deep and odd flaws. Consider that Vim has been
around <a data-noreplace="1" href="/web/20130601181333/http://en.wikipedia.org/wiki/Vim_(text_editor)">since 1991</a>. Pathogen,
the first widely used, known, and celebrated path manager making plugin
management possible, was released in 2008! Before that, you were encouraged to
<strong>recursively copy the plugin’s directory into your Vim folder</strong>. I’m not
kidding. There’s even a special, praised shit-format in Vim for doing this,
called a Vimball (VBA). Many plugins scripts still use this format. Try
uninstalling a plugin that you copied into 10 folders a few months ago. Try
upgrading it!</p>

<p>Vim is touted as being an extensible, customizable editor, and it is. It’s
probably the most customizable editor ever, but we never had any proper package
management until very recently. This is worrying. Vundle didn’t even come out
until 2 years after pathogen. Even pathogen and vundle are limited compared to
Sublime Text’s Package Control plugin.</p>

<p>This is all especially scary because <strong>Vim out of the box is awful.</strong> I can’t
stress how bad of an editor vanilla Vim is. Plugins are <strong>essential</strong> to make Vim
usable.</p>

<h2>Plugins and Extensibility 2: Ecosystem</h2>

<p><a href="/web/20130601181333/http://www.vim.org/scripts/index.php">Vim Scripts</a>. Barf. Think CPAN with
less formatting, fewer features, and more ads.</p>

<p>Most Vim plugins haven’t been converted to <a href="/web/20130601181333/https://github.com/">Github</a>
projects yet. Vim Scripts acts as a featureless host, which is fine, except that
it doesn’t offer any benefits. It has a nasty interface, and encourages the use
of the <a href="/web/20130601181333/http://vim.wikia.com/wiki/Vim_Tips_Wiki">Vim Wiki</a> for project
management (more on that later). Much of the Vim plugin community revolves
around this barfy site. There is an effort being made to
<a href="/web/20130601181333/http://vim-scripts.org/">auto-convert</a> Vim scripts to Github projects which may
be promising, or may be a disaster.</p>

<h2>Plugins and Extensibility 3: Vimscript</h2>

<p>Ah, Vimscript. It’s bad. And yet we’re stuck with it. <strong>If you want to write a
plugin you have to deal with Vimscript.</strong> It isn’t necessarily a bad language.
The syntax is a little goofy but it’s forgivable. The main problem with
Vimscript is that it’s <strong>not</strong> another language. No one knows it. <strong>Most
experienced Vimmers I know don’t know any Vimscript.</strong> And how would they? The
documentation on it is terrible, and made much worse by the fact that it’s near
impossible to look up help on it.</p>

<p>You might find a Vimscript tutorial on the <a href="/web/20130601181333/http://vim.wikia.com/wiki/Vim_Tips_Wiki">Vim Wiki</a>
(try searching for Vimscript to learn just how bad their search is, another
reason not to use it), but I honestly think most of the authors have some
personality disorder. There are no friendly, accessible, story-like tutorial to
be found. It’s documented by robots and emotionless coders.</p>

<p>Let’s say you want to write a function. Ok. let’s look up the help for function.
<code>:help function.</code> Oh good, this isn’t what we want at all. Let’s type <code>:help
vimscript</code> I guess. What the fuck is this? <em>Side note: all of Vim’s help is
equally poorly accessible</em>. Fortunately, a few good resource sites exist
(<a href="/web/20130601181333/http://learnvimscriptthehardway.stevelosh.com/">Learn Vimscript the Hard Way</a>).</p>

<p><strong>But even Vimmers don’t want to learn Vimscript</strong>. God willing Vim will one day
have a non-Vimscript language we can use. There have been discussions of making
Vim adopt ECMAScript (<a href="/web/20130601181333/http://www.mail-archive.com/[email protected]/msg03698.html">Re: replace VimScript</a>)
but no one has had the balls to attempt it, including myself.</p>

<h2>Plugins and Extensibility 4: Collisions</h2>

<p>This is a big one. <strong>Vim is missing an incredible amount of core functionality
for modern editing.</strong> Things like ctag integration, project management, project
browsing, (yes I know about :Sex), and many other basic things, are completely
absent in Vim. <strong>This is by design</strong> because Vim was never meant to edit any
single language, except maybe C. This isn’t necessarily a bad thing! Vim can in
theory edit any language because of its extinsibility power, although it will
have a very hard time with IDE-languages like Java or Scala.</p>

<p>Ok, we need a project-like file browser. Let’s get
<a href="/web/20130601181333/https://github.com/scrooloose/nerdtree">NERDTree</a>, most people know
about that. But wait, NERDTree keeps leaving shitty things open when I close
buffers. Most people don’t know about <a href="/web/20130601181333/https://github.com/jistr/vim-nerdtree-tabs">NERDTree tabs</a>,
but NERDTree is incomplete without it. 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…</p>

<p>Now we need to find files. Let’s use Vimgrep! Oh wait, that sucks. Ok let’s get
<a href="/web/20130601181333/http://www.vim.org/scripts/script.php?script_id=3025">Command-T</a>. Oh wait
that’s incredibly slow and clunky and looks jenky. Oh, there’s
<a href="/web/20130601181333/https://github.com/kien/ctrlp.vim">CtrlP</a> this is much nicer! Except, wait it
<a href="/web/20130601181333/https://github.com/kien/ctrlp.vim/issues/110">doesn’t actually do correct fuzzy searching</a>, so now my results are
inaccurate. Do I want slow and stupid or do I want fast and wrong? Or do I
wan-<strong>fuck it</strong>.</p>

<p>Sublime Text’s Command-T “just works”, works incredibly well, looks amazing
making scanning files 100% easier. Padding around your text to make it readable?
What a concept!</p>

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

<p>Back to collisions, there are many plugins which touch the same functionality,
because default Vim offers so little. Need snippet completion? Get
<a href="/web/20130601181333/http://www.vim.org/scripts/script.php?script_id=2540">snipMate</a>! But wait,
<a href="/web/20130601181333/https://github.com/SirVer/ultisnips">UltiSnips</a> is better! But wait, both go
into hell if you have <a href="/web/20130601181333/https://github.com/Shougo/neocomplcache">neocomplcache</a>
installed! <em>(Side note, I couldn’t pick a worse name than ‘neocomplcache’ if I
were offered 10 million in unmarked bills to accomplish it).</em> Now you need
<a href="/web/20130601181333/https://github.com/Shougo/neosnippet">neosnippet</a>! But wait, if you have any
other auto complete plugin it will fail! And all of these plugins are
gauranteed to fuck up Vim’s default, already complex and confusing auto
completion!</p>

<p>Your search plugin will collide with your auto complete plugin. Your syntax
plugin will collide with your dictionary. <strong>What does a collision mean?</strong> 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. You’ll get
cryptic errors with function names you’ve never seen before if your search regex
is invalid, from
<a href="/web/20130601181333/http://www.vim.org/scripts/script.php?script_id=1682">indexed-search</a> (which
you want, because why the hell isn’t that in Vim by default). 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.</p>

<p>Ah, the extensibility of Vim.</p>

<h2>Vim Is Bad By Design™ 1: Oooooollllld</h2>

<p>Everyone remaps <code>Leader</code> from backslash to comma. 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, but it’s worth it to avoid the archaic backslash leader.</p>

<p>Do you know what the suggested way to work well with multiple files in Vim is?
It’s the arglist. 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. It can actually be quite handy at times (with a few
plugins), but you may only use it three times in your whole Vim career. It’s a
weird, archaic, specialized knowledge wart of Vim. <strong>And you’re going to need to
know it,</strong> probably around year 2.5.</p>

<h2>Vim Is Bad By Design™ 2: GUI</h2>

<p>Vim is designed to run in a terminal. That’s why it’s explicitly linked to
<em>only</em> 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. 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.</p>

<p><strong>But Vim is supposed to be an editor that you don’t always have to use on a
server.</strong> You can use <a data-noreplace="1" href="/web/20130601181333/http://en.wikipedia.org/wiki/Pico_(text_editor)">Pico</a> on
a server as well, but no one uses Pico to do actual long term editing. <strong>Here in
the future, we have these things called GUIs</strong>. They’re super nice! They look
good, are usable, and give useful visual metaphors for things. And we logically
and reasonably expect our editors running on GUIs to offer the same benefits.</p>

<p>Do you know what benefit <a href="/web/20130601181333/https://code.google.com/p/macvim/">MacVim</a> has over
terminal Vim, visually? It has styled tabs. <strong>That’s all we get, and that’s all
we’ll ever get.</strong> Text cannot nor ever will have padding for readability. You
cannot show more than one font size on the screen at once. If you want to
zoom in your buffer text, you also zoom in your file browser. 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.</p>

<p><strong>Vim is hideous by design.</strong> It looks like a child just learning how to draw a
cow with a bash script made it. We will never have a
<a href="/web/20130601181333/http://programmers.stackexchange.com/questions/156362/does-sublimes-minimap-improve-productivity">minimap</a>
(beautiful feature). We will never have multiple cursors. We will never have a
pretty fuzzy file finder that pops up in a reasonable location. We can’t place
dialogs in arbitrary places for usability. We will never have a customizable
dialog anything. The closest you can get is
<a href="/web/20130601181333/https://github.com/Lokaltog/vim-powerline">vim-powerline</a>, and that’s still
just drawing with blocks. 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. <strong>Vim has lots of neat bells and whistles, but many of them are just hacks
and tricks to get around the fact that we don’t have a real GUI.</strong></p>

<h2>Vim is Oddly Bad at Indenting</h2>

<p>Don’t believe me? Paste this into an empty buffer:</p>

<pre><code>&lt;div&gt;
&lt;p&gt;
&lt;span&gt;foo&lt;/span&gt;
&lt;/p&gt;
&lt;/div&gt;
</code></pre>

<p><code>:set ft=html</code> and then <code>gg=G</code>. Let me know what you get. In all
seriousness, never, ever tell me what you get.</p>

<p><strong>For some strange reason Vim is bad at most indenting</strong>. Forget about having
your javascript indenting work right. After messing with <code>cindent</code> and
<code>smarttab</code> and <code>shiftwidth</code> you’ll turn to plugins, you’ll find
<a href="/web/20130601181333/https://github.com/pangloss/vim-javascript">javascript.vim</a> 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.</p>

<h2>The Life Long Vim Journey to get a Reasonably Usable Editor</h2>

<p><em>*To code in Vim, you have to keep Vim in your head just as much as the code
that you’re editing.</em> You have to constantly think about what you’re doing.</p>

<p>Maybe this is a good thing. Maybe it encourages efficiency and refinement of
practices. <strong>But you know what? I don’t want to deal with that.</strong> I don’t want
to have to remember what <code>@@</code> does or what <code>:v/\v</code> does or a fractal web of
things to accomplish basic tasks. Despite this, I do. I spend at least an hour a
week working on Vim-fu. But I don’t want to. I want to edit text. I don’t want
to read yet another tutorial that counteracts something else I had finally got
down so that I can rename a function correctly. I just want to make things.
Perhaps it’s a necessary evil. Perhaps at year 10 it will all have been worth it
because I won’t have to think to do things. I don’t know.</p>

<h2>After four years of Vim use, 700 hand written lines in my <a href="/web/20130601181333/https://github.com/DelvarWorld/configs/blob/master/.vimrc">.vimrc</a>, and 45 plugins, I cannot in good faith recommend that someone start the Vim journey.</h2>

<p>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.</p>

<p>Look kid, I love you and all, but just use <a href="/web/20130601181333/http://www.sublimetext.com/">Sublime Text</a>.
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.</p>

<p><strong>You’re going to have to know Vim.</strong> 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 <em>will</em> be using Vim for. You won’t be able to live
without <code>set -o vi</code> on the command line to get Vi bindings in bash, and I will
judge you forever until you actually use it…</p>

<p>But Sublime has things Vim can never have. It’s the new hotness and has a more
active community than Vim does. You’re lucky to see a Vim plugin that has been
updated in the last year (not to diminish the incredible work of superstars like
<a href="/web/20130601181333/https://twitter.com/tpope">Tim Pope</a>, who I would kill for, but they are few
and far between).</p>

<p>Vim is a <a href="/web/20130601181333/http://www.rayninfo.co.uk/vimtips.html">lifelong journey</a>. 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.</p>

<p>If you find Sublime isn’t for you, or feel like you’re missing power, then you
can try Vim. But you can get by with editing files on servers with minimal Vim
knowledge. You can use <code>set -o vi</code> without reading a book.</p>

<p>My opinion may change in later years,</p>

<p><strong>but for now, if you need to make a choice, just use Sublime Text.</strong></p>

<p>(oh, <code>:set tw=10000 | norm gqie</code>, with textobj-entire, duh)</p>
</div>


  <footer>
    <p class="meta">
<span class="byline author vcard">Posted by <span class="fn">Andrew Ray</span></span>
<time datetime="2013-03-16T19:06:00-07:00" pubdate="" data-updated="true">Mar 16<span>th</span>, 2013</time>
<span class="categories">
    <a class="category" href="/web/20130601181333/http://delvarworld.github.io/blog/categories/editors/">editors</a>
</span>
    </p>
      <div class="sharing">
  
  <iframe data-twttr-rendered="true" title="Twitter Tweet Button" style="width: 107px; height: 20px;" class="twitter-share-button twitter-count-horizontal" src="https://platform.twitter.com/widgets/tweet_button.1368146021.html#_=1424969293087&amp;count=horizontal&amp;counturl=http%3A%2F%2FDelvarWorld.github.com%2Fblog%2F2013%2F03%2F16%2Fjust-use-sublime-text%2F&amp;id=twitter-widget-0&amp;lang=en&amp;original_referer=https%3A%2F%2Fweb.archive.org%2Fweb%2F20130601181333%2Fhttp%3A%2F%2Fdelvarworld.github.io%2Fblog%2F2013%2F03%2F16%2Fjust-use-sublime-text&amp;size=m&amp;text=Just%20Use%20Sublime%20Text%20-%20Andrew%20Ray's%20Github%20Blog&amp;url=http%3A%2F%2FDelvarWorld.github.com%2Fblog%2F2013%2F03%2F16%2Fjust-use-sublime-text%2F" allowtransparency="true" scrolling="no" frameborder="0"></iframe>
</div>
  </footer>