Source editor worth $70
November 14th, 2013 by Eugene Ostroukhov

I’ve been a devoted Eclipse user for more then a decade (with most of that time spent developing applications based on Eclipse) but I’ve noticed that I am becoming less and less inclined to spend my time trying to convince Eclipse to actually edit my files. I ended up using  Eclipse only for Java – Xcode is great C++/C (libclang-powered editor with C++11 support) with VIM was standard for all other files. For the last couple months I’ve been slowly migrating to Sublime – now I reached the point when I even consider using it for Java files.

This is just a “disgruntled veteran Eclipse user” view on why it is worth it to pay for your coding editor these days.

It can open files! And folders…

Cmd+S, Cmd+N and Cmd+O are the first shortcuts everybody learns. Eclipse is unique in that it breaks this convention. “Open File” is an afterthought (doesn’t even have a key shortcut), with many plugins unable to work with those files – even if your editor manages not to show an error dialog (or dump an exception in log) – some features still are not available.

Sublime not just behaves as expected – it goes one step further. I can “open” any folder – showing that folder in the Sublime “Project Explorer”-like pane. What is truly surprising is that Sublime manages to deliver many Eclipse  killer features – including “Open Resource…” and “Goto Symbol in Project” (think JDT/CDT “Find Type” and “Find Function”). No metadata files is created in those folders, no indexer is ran. Right now my “workspace” has a mix of Bootstrap-based HTML application with a Python server-side – and without any plugins I can immediately focus on a CSS rule or on a Python function. I’ve also shown to my colleagues that I can open mid-sized C projects and be able to open random function within seconds. No setup, no long-running background jobs.

It opens shell scripts, .ini files without spinning up Xcode or any other heavy “external editor”.

Editor is the same

Cmd+Shift+R will go to symbol in any file in any language (that I tried) – in Eclipse, CDT and JDT installed in the same workbench have confusing separate realms with Cmd+Shift+T been bound to different dialogs depending on active editor. Cmd+Shift+R and Cmd+Shift+A are yet other parallel realms, adding to the confusion.

Sublime can expand selection to enclosing scope in Dita XML, Python or in JavaScript. Sublime actually even unifies Eclipse-like “Goto line” and “Quick outline” popups into “Goto Everything” – I’ve been wondering for years why Eclipse uses separate pop-ups for that.

One prominent Sublime feature is multiple cursors. Curiously, this feature is really familiar to JDT and CDT users – you can see multiple cursors when you rename variables. In Sublime multiple cursors can be used to select search results (quite similar to Eclipse rename refactoring) or to apply edits to several separate locations at once.

No mouse

I spend most my time in Eclipse having source editor maximized (I also used to hide toolbar – until I started using Eclipse Kepler where Cmd+3 makes toolbar visible no matter what).

In Sublime I can split the window (not the editor 😉 ) using just the keyboard. I can move editors between stacks or focus on stacks without reaching the mouse. Switching between editor predictably opens a tab to left/right – instead of randomly popping from the recent editors stack.


There is no preferences UI as such in Sublime – keybindings and settings are stored in JSON files that are editable in the text editor.

Plenty of plugins, easy discovery. “Cmd+Shift+P”, “Install<Return>”, type filter string. Plugin is found and installed even before “Marketplace client” would open.

Files can be opened from the command-line. Reliably. Even on Mac.

Missing parts?

Sublime does not integrate SCM support. Well, there are some plugins – but I haven’t figured them out yet, mostly because I am command-line Git and Perforce user (as not all my files are in the workspace) – the only thing I miss is Perforce checkout from the editor.

No debugger UI. Surprisingly, no biggie – JavaScript users are using browser anyways, C* users get to keep their GDB/LLDB primed.

No way to run shell command from within the editor. As in VIM.

Next generation

IntelliJ and Eclipse were revolutionary tools – they eschewed RAD features and visual designers that were a cornerstone of the IDE experience and focused on the core programming experience instead – providing ultimate source editor, making refactoring mainstream. Sublime seems to do the same trick – only this time it is Eclipse that is slow and outdated. Sublime does not force me to manage workspaces (in couple weeks I will have to start working in a different branch (in Perforce it is a different folder) – ain’t it fun, with my 20+ projects?), flip perspectives (the first thing I show to QA or new team members – “If you don’t understand what’s going on on the screen, do “Window > Reset perspective”) or wait till my cancel button click is honored. Again, as 10 years ago, I’m enjoying my editor instead of wrestling with it…

Indeed, times, they are a-changing…

8 Responses  
  • Mickael writes:
    November 15th, 201312:57 amat

    Hi, It seems like you have a very good focus on usability and that you’ve had “for years” (quoting yourself) some good ideas of how to improve Eclipse. Have you put them in the Bugzilla? If not, that’s a pity, I guess some of them would have raised interest and would have been fixed 5 releases ago. The Eclipse Platform is still really productive, and the issues of Eclipse are for mostly not related to technology, but more related to lack of focus on ergonomics, where most of Eclipse developers don’t excel. Technically, there’s nothing Eclipse couldn’t do now, it’s far from being technically dead. We used to count on users to raise bugs and suggest enhancements in term of usability, but unfortunately there’s something broken in the community engagement process that makes that many users just keep there complaints for themselves instead of suggesting improvements.

    In order to avoid loosing those good ideas, I turned some of them remarks into bugs and mails: * * *

    As for metadata file, I just guess that the metadata are re-created and re-loaded everytime in memory instead of filesystem.

    • Eugene Ostroukhov writes:
      November 15th, 20139:25 amat

      Michael, I see no pointin raising bugs. In myexperience, even if you submit a bug, spend hours working on a patch – it will just be ignored. Even if it is a bug fix for an obvious bug.

      • Mickael writes:
        November 15th, 20139:38 amat

        It may have been true to some extent, but I have the impression the the Platform team handles contributions faster now (maybe thanks to Git/Gerrit). It’s still sometimes necessary to be insistent in getting a contribution merged in order to convince the team of the value of a change, and it is true for OSS in general. Raising bugs and contributing patches are definitely the only way to make things happen in Platform. Not opening bugs, and Not contributing in general is fore sure a way to become unsatisfied about the product. And to end up by having to buy a 70$ editors when a few bugs and some lobbying would have sufficed.

        • Eugene Ostroukhov writes:
          November 16th, 20132:42 pmat

          I spent more then $70 on “friends of Eclipse” alone (on top of that, add conference fees, man/hours submitting bug fixes to different projects) – but that’s beyond the point. My experience is that you will be ignored unless you work for a “friendly” company – e.g. see, that’s committer explaining how it works.

          • Mickael writes:
            November 17th, 201310:22 pmat

            I tend to agree that contributing to OSS is somehow more expensive that just buying a tool that works. However, contributing is not meant to reduce prices, it’s meant to have some knowledge and control on the future of the software. What you say about being part of friendly is wrong. And if you have some examples showing it’s happening, you should send mails to Wayne about that, as this behaviour is prohibited by the Eclipse community rules. You get ignored until you succeed to convince the project team to handle your bug. This can be made easier by insisting on clear use-cases, and contributing patches. The discussion you link doesn’t speak about “friendly” companies but more of how committers are responsible of integrating and maintaining patches, although contributing to Eclipse is generally not a full-time activity; and of how this makes it more difficult for committers to accept patches.

          • Lars Vogel writes:
            November 18th, 20132:02 amat

            Hi Eugene,

            Thanks for the summary, I think their is lot to learn from other editors and its is great that you placed so much effort in this description which hopefully helps us to improve Eclipse.

   is a personal view of one committer and maybe a sign why certain projects has not been good with accepting patches in the past.

            I hope that the platform team, which I recently joined, is better in that sense. We really appreciate patches and contributions. One restriction platform currently has is that it cannot break API. One thing which really helps is to create a Gerrit review, you typically receive relatively fast feedback. I created a small description which hopefully makes the setup easier:

            In case you have pending patches for Eclipse platform, please let me know.

            Best regards, Lars

  • Jan writes:
    November 15th, 20131:04 amat

    To execute shell commands you could use SublimeREPL

    • Eugene Ostroukhov writes:
      November 16th, 20132:26 pmat

      Awesome – I haven’t tried it for running terminal commands, but now my son can use Sublime instead of IDLE to learn Python.

»  Substance:WordPress   »  Style:Ahren Ahimsa