Review: Sublime Text 2

Sublime Text 2 is a hot, capable text editor crippled to the point of uselessness by lousy documentation, an unresponsive developer and a community that reminds me of mid-'80s BMW owners: they shy away from any hint that they bought a lemon.

I've given a first-impressions review of Sublime Text (ST) already.  In it I promised to give it a proper review after a month or two of use.  This is that review and, honestly, I could hardly wait to write this.  This is not a good thing.  You see, the reason I'm eager to write this review is that it means I won't have to use ST as my primary development editor for any longer.  (I can't really honestly review something I don't use, after all.)  I'm anxious to get this review behind me because the experience of using ST was that painful.


Yes, this is going to be a negative review.  If you're an ST fanboi who can't stand facing some unpleasant truths, please feel free to stop reading at this point.  You won't like what comes next.  (If you're going to get upset that I'm judging this software more harshly than I'll be judging other software I review here, keep in mind that I hold software I paid for to far higher standards than I hold F/OSS software.  If you want my money, I expect certain amounts of professionalism from you.  It's that simple.)


For the record, this review is based on Sublime Text 2 build 2217 running on Linux Mint 11.  Some issues may have been fixed in the interim (but probably not: c.f. below under "unresponsive developer").

The Good

This review is going to be negative, yes, but it won't be unremittingly negative.  ST is, you see, a very capable editor out of the box, and with its high degree of customization it can be made even more capable with relative ease.  These are some of the features I'd like to call attention to in particular as well-thought-out and often even well-executed.


Once you actually find the documentation for it, the editing facilities of ST are stupidly powerful.  Only Vim, of the editors I use, is more powerful, and there it is only marginally so.  I'd say that the difference in power between ST and Vim falls into metaphorical rounding error levels of difference.  Were it not for the issues I outline below (foreshadowing: a sign of quality writing!) I'd have no problems whatsoever replacing Vim with ST as my programmer's editor of choice.  Some of the features I appreciate are:

  • multiple selection – It's possible in Vim (via a plugin), but much easier (and out of the box) in ST.  As a result I'd actually use this feature in ST.
  • "Goto Anything" – Man, how do I describe this to people who haven't experienced it?  You hit Ctrl+P, you start typing, ST searches, live and before your eyes, all files you've got open, or all files in opened directories, for that name.  Want to search for text in a file?  Append # to the file name and start typing your keyword.  All files that match the (fuzzy) file name you've given it are now searched for the keyword you're tying.  Want to find a specific symbol?  Use @ instead.  Want to go to a specific line number?  Use :.  This will be the single feature of ST I miss most when I delete it from my system.
  • plugins – ST is amazingly extensible, easily in the league of Emacs or Vim, but, in my opinion, superior to both in that plugins are far more coherent and better-integrated into the editor's framework.  This means that plugins' commands get added to the command palette transparently and are thus just as easily searched (using fuzzy search) as built-in commands.  Which leads me to…
  • the command palette – I will really miss this when I switch back to VimVery quickly and with very few keystrokes I can hit any command provided by any portion of the system (including, as mentioned above, plugins).  When I compare this to the anemic nonsense that is Vim's approach to integrating commands and invoking them (and, very probably, Emacs' too) I shed a small tear.

Indeed the only feature in editing proper I think was done badly was the fake columnar editing.  That was a disappointment (and was incorrectly documented to boot).

Project management

This is something sort of between session management and full-tilt IDE-style project handling.  A "project" in ST is a list of files and directories you're working on for a given work unit, plus extra information on the files, the project-specific settings (including build system settings), etc.  You can read about them in the official docs.  They're conceptually simple, but very nice.

Build system integration

While I don't use this feature (preferring good old console interfaces and typing "make"), I do appreciate that my tastes are in the minority here.  ST is a text editor, but it features some functionality that makes it a lightweight IDE as well should you want this.  So does Vim, of course, but unlike Vim, where such integration with build tools is ad-hoc and, as a consequence, no two build system integration tools work together coherently.  ST's build system integration is far superior.  It's easier to set up, easier to modify and easier to use.  It's not quite at the point where I'd want to use it, but, as I said, this is a personal quirk and I appreciate that not everybody agrees with this view.

The Bad

This is the meat of the review.  This is a sad statement for me because I really, really, really wanted to like ST, but the piling of one misfeature atop another in endless succession just eliminated any chance of me ever using the package.

Textual configuration for everything

Pretty much everything in ST is configured via JSON files.  Of course the keys and values are mostly undocumented.  You have to guess how to set things up by looking at other configuration files or by asking questions in the community.  All the work that was put into making ST look slick and mean out of the box just falls apart as soon as you want to configure things.  Instead of having options turned on and off, or having them adjusted, all within an error-checking framework that validates input and ensures your configuration is workable, you get a text file straight out of the '70s.  And just like the '70s, if you make a typo in your config file, you can wind up with an unusable (and pretty much undiagnosable) editor configuration.  You had better fire up your SCM if you want to make any changes.


Even worse than this, there are literally hundreds to thousands of these files (!).  I am not exaggerating here.  There are 1015 such files on my system, not including copies in the Backup or Pristine Packages directories.  Good luck finding the right one if you're doing anything even slightly complicated!  Why is this so hard?  Because there's a hierarchy of files consulted, so if you change something in the wrong file, it may be overridden in a file that's loaded later.


What's that?  You want all of the configuration options documented in meaningful and coherent ways?!  BWAHAHAHAHAHAHAHAAHHAHAHAHAHAH!  Whew!  Good one!  I actually had to wipe a tear out of my eye.


Oh, wait!  Did I say that almost everything is JSON?  Of course I meant to say that everything is JSON except, for some unknown (well, because they're actually ripped off from Textmate) reason, code snippets.  Those are XML files.  X-fucking-ML, yes.  Consistency for the win!

Indentation gone wild!

Where do I begin here?  Let's begin with the official (for a change!) docs.  Look at the priority order for indentation settings in files.  Count the different files you'd have to adjust if you want to, say, change all of your indentation to using spaces by default.  (Hint: one per language you use.  I guess if you're just a one-trick pony type that uses: 1. Objective-C and 2. nothing else, this won't be much of an issue.  If, however, you're even just a web developer you're already editing upwards of probably seven or eight files to get things set up the way you like.)


Now this is true for Vim as well, I should point out.  The difference is that I can easily and quickly change those settings while I'm using Vim should I wish to.  I can't in ST.  I have to find the right file and edit it (making sure I don't screw up the syntax in a typo!).  I can't do it once for a session easily.

Anaemic macros

There are weird restrictions on what macros can record.  You can't, for example, create a new file or open an existing file in a recorded macro because "window level commands" aren't recorded, only commands "sent to the buffer" are.  This doesn't make macros useless, but it sure does weaken them tremendously.


Even worse, however, is that macros appear to be accessible only via the Tools → Macros menu.  There's nothing like Vim's q-registers which can be accessed almost instantly via @.  This means that session-specific macros are a pain and, as a result, are unlikely to be actually used.

Broken session management

Every time I run ST, it opens on screen 1 at the top right.  It defaults to a width×height of 64×23.5 characters×lines.  (WHY?!)  I move it to screen 2 and make it full-screen.  I close it.  I restart it.  It's back to screen1/top-right/64×23.5.  OK, so I keep it on screen 1 and just make it less stupid in size.  And I move it to the left hand side.  I close it.  I reopen it.  It's back to … well, you can guess.  Now doing this the right way (which is to say storing the window dimensions and position) is supposedly supported.  But it isn't.


OK, window placement's not a big deal.  I've got hotkeys in my window manager that let me position windows to where I want them quickly and easily.  So let me try something else.  I'll go to one of my development directories and fire up the editor.  I'll then open all the files in the directory.  (Then I'll reposition the window somewhere useful.  Just thought I'd get that jab in again.)  Now I'll close the editor.  Let's fire up the editor again.  Did the files I last used get re-opened?  No.  Fair enough.  Vim doesn't do that either, but several other editors I use do.  It was an interesting test.  I'll just go to File → Open Recent → …  and …  Oops!  Nothing there either.


WTF is there even an "Open Recent" entry in the menu for if it doesn't list recently-opened files?!

Badly-written docs

The main source of documentation for ST is the unofficial documentation site.  (Yes.  The main source of ST's documentation is an unofficial manual written by its paying customers.  Ladies and gentlemen, I give you professionalism!  Give it a big hand, 'cause you won't see much of it in the ST experience!)


Here's an example of bad writing from early on in the docs.  In the tips for single-file search and replace the first entry helpfully informs us "Goto Anything provides the operator # to search in the current buffer."  What's the problem?  By this point in the documentation "Goto Anything" hasn't been explained (nor even named) yet.  There's not even a link to what it is.


There's dozens of examples like this to be found.  This is what happens when you decide not to document your product, relying instead on amateur fanbois to do your work for you.


Now I don't want to be too harsh here.  The documentation for extending ST through plug-ins is actually quite good.  (The tutorial is good too.)  Were I going to use ST as my text editor of choice, I'd be very pleased at the documentation here (because I use a lot of languages that are decidedly not mainstream, so I'd have to write plugins for them myself).

Stupid, stupid docs

You're going to think I'm making these quotes up just to be mean.  To prove this isn't the case I'll be linking to the page from which I extracted them.  (In some cases the issues I raise here might get fixed.  You'll have to search the wiki's history to find the quotes in this case.)  This, as above with bad writing, is just a sampling.  I broke it out into its own category of hurt because this kind of crap deserves to be mocked.

The Ugly

Some things go beyond bad (or are at least orthogonal to the good/bad axis).  They're not necessarily reflections on the product directly but they're definitely part of the user experience and thus important to note.

Unresponsive developer

Jon Skinner is a good developer.  He is, however, a lousy communicator.  Really lousy.  This goes beyond the documentation issues I've already belaboured above and into the whole "interaction with the customer base" thing.  He is in desperate need of some kind of assistance in this regard; autism is not a good basis for customer relations.


For some examples, consider the Sublime Text blog.  For the entire year of 2012 he wrote three entries.  Each of those entries just announced a new release with, basically, a list of changes.  They read like (and serve the function of) press releases only they don't work well as press releases because they're so infrequent and so rare nobody sane would be checking the blog anyway.


Even 140 characters at a time Mr. Skinner is incapable of connecting to his customer base (not to mention his potential customer base).  I count 18 tweets over 2012.  If each of these was maximum size (they aren't), that's less than 2.5KB of text over a year.  I'd wager this review alone is over 2.5KB.  (Yeah, yeah.  I know.  Brevity … is wit.  —Shakespeare)


OK, so maybe he's just not a blogger or a twit.  Surely he communicates more on his own forum, right?  Well, yes, actually, he does.  Just not in any useful way.  This question, for example, at the time of writing, was unanswered for almost a month.  This is something that I eventually found the answer for by harassing the community's IRC channel until I got an answer.  (C.f. below "ostrich-like community" for why harassment was needed.)  It's also something the developer of the package could have answered in his own tech support forum in seconds.


Other signs of total disinterest in communicating with his customer base are:

  • A link to a web site for feature requests … which he barely ever visibly responds to.
  • No kind of bug reporting/tracking system.

I guess you just have to care about the people who paid you, though, before any of these kinds of things occur to you.

Well, he responds quickly in some circumstances...

I am being a bit unfair to Mr. Skinner.  Whenever money is involved he communicates very quickly.  When I bought my license, it was processed very quickly and my license was sent right away.  When he increases the price, that, too, is communicated very quickly and clearly.  It's just the rest of the whole communication thing that he's bad at.

Ostrich-like community

ST's fans are big fans.  They really like the editor and evangelize it at every opportunity.  (The only reason I bought a copy, despite my restricted pecuniary circumstances is because of the buzz around it, combined with the strong recommendations of several people whose opinions I respect.  Not for much longer, though, if this kind of thing keeps up…)


There are problems with this kind of fan, however:

  1. Blame the victim.  When things don't work, this kind of fan tends to immediately reach for "works for me, you must have done something wrong".  The #sublimetext channel on Freenode is a major source of this.  When it bothers to respond at all, I mean, which segues nicely into…
  2. Ignore the problem.  I mentioned having to harass the IRC channel to get an answer to a problem.  Why did harassment have to get involved?  Because any question that isn't some variant of "man, isn't ST great?!" is almost utterly ignored on that channel.  This tendency was acidicly commented on by a denizen there (not me, I swear!): is this #sublimetext or #idleRPG? :(

ST's fans, in short, are such fans of ST that they try and edit their world so that its problems don't exist for them.

Only Mac users need apply

Yes, ST is supposed to be cross-platform.  The sad reality, however, is that it's an OSX package.  That gets many of its features ported to Windows in a reasonable amount of time.  And that treats Linux systems as a red-headed stepchild of an afterthought.  Since I will never, ever buy Apple or Microsoft kit ever again, that leaves me in the red-headed stepchild of an afterthought category.  Maybe people who like supporting abusive corporate entities find ST a satisfying experience.  I, as a Linux user, do not.  (And if you're a *BSD user you're basically fucked.)


I really wanted to like ST.  Indeed at a certain level I actually do.  I think it's a very capable editor engine at its core.  It's fast.  It's slick.  It's pretty.  It's powerful.  All that being said, however, it's also $59^W$70 (as of the most recent update from the developer).  Were this a F/OSS project I'd be an enthusiastic user (and maybe even a contributor, especially to the documentation or some language-specific plugins).  It is not.  It is paid software and, as such, it is simply not worth the money.  If I want to hack around limitations of software and to ram my head against a wall of badly-written, incorrect or just plain missing documentation I sure do not want to pay for the privilege!


Someday, should the developer ever turn this into a real product, Sublime Text will be a great piece of software.  And someday, should Linux support be something more than an afterthought, it may even be usefully cross-platform.  Until that day arrives I'll be looking elsewhere.