The story of TextMate, VIM and SublimeText
progfu.com
progfu.com
This seems kind of grouchy I know, but I am getting a bit tired of these wildly overblown titles attached to very thin blog posts. I knew what I'd see when I clicked the link and was just as disappointed as I'd expected to be. I guess I have a masochistic streak.
The actual stories of those three editors, their authors and how those stories intertwine would probably be pretty interesting. I guess I'll have to wait for This American Life to tackle it.
Emacs has a much better Vim mode for me than SublimeText 2, but neither can really give you Vim. The deeper you are in the Vim rabbit hole, the less likely you will be to return to try anything else.
Emacs wins out against everyone for scripting.
There is one other reason that I knew would always keep me in the Vim and Emacs world. At first I couldn't figure out what it was that bothered me about SublimeText 2. Vim and Emacs is open source! I don't see this point mentioned in arguments for or against but this is important to me.
Vim can use ctags or cscope or clang, but that is not the same thing. These are great tools, but they need to be set up with the correct include paths and they need to be run regularly to be useful.
To my mind, that is what makes Emacs so unique and powerful and that is something that really, no other program can hope to accomplish in a short time frame (sorry, Sublime Text).
That said, Vim hands down beats Emacs when it comes to pure text editing speed. It's keybindings are just a lot more powerful and flexible than Emacs's. And of course, that is what evil-mode is for. It emulates a subset of Vim in Emacs. It is by far the best simulation of Vim I have ever seen (judging from ViEmu, Viper, Vintage, Vico and Vimpulse), but it is not the real thing. Plus, there are lots of great Vim plugins that do not work in evil-mode.
I, for one, use Emacs and Evil and I am happy with it.
And I hope that Sublime Text will provide a potent entry-level drug for the next generation. But really, without open sourcing it at some point, I can't see it catching up to The Big Two.
The SublimeClang plugin for Sublime will do this, pretty much. You may have to add a few paths to its global or per-project config file, but that's pretty obvious considering that it needs them to parse referenced files. It works extremely well, giving you autocompletion of any C/C++ symbol as well as automatic compilation error indicators.
Well, Emacs has that stuff built-in, and better. That is precisely the way in which Emacs is more powerful than Sublime or Vim.
The modularity means that the core application itself is small and simple, with fewer moving parts than something huge like Emacs. It also means that I have the freedom not to install something that would otherwise come bundled with/tangled with the app. Everybody wins.
SublimeClang requires a minimal amount of config, is dead easy to install, and it relies on external toolset by design, because building everything in would be insane. I very much prefer that Sublime does not come with this functionality.
(I don't know what you mean by "have to be run regularly", btw. SublimeClang can run continuously and transparently.)
Emacs doesn't come with everything built-in. But when you extend Emacs, you usually do it entirely in Emacs with Elisp. Emacs libraries rarely call external tools - they usually implement the tools inside Emacs.
I have no idea if that's the case, but if it's not, there is no functional difference between that and any other editor, where you need to install a separate plugin.
Sublime itself can be extended with Python. To me, that's a better solution than a proprietary (albeit Lisp-based) language.
Whether those plugins "call external tools" or not is of little importance, although relying, in a modular fashion, on pre-existing software is more Unixy.
I'm sure Emacs' tag system is powerful, but personally, I would rather have something like SublimeClang, which is built on a high-quality, highly maintained C/C++ compiler toolchain that retain type information and so on, than some kind of tag system based on a superficial parser designed purely for code inference.
I was simply saying that Emacs can open a C++ file and have all tags and completions right there, no setup required. No external application required either. That is the power of Emacs and that is a power not available to Sublime Text (unless you write your own C++ parser in Python).
You see, clang is an awesome tool and I'm sure its integration in Sublime Text is very good. But by its design it can not look for headers in appropriate locations without someone explicitly telling it to do so. Also it can not parse partially erroneous code. Both these actions are just not sensible actions for a compiler.
And that is why no external tool can ever provide the integration and practicability of a tool purposely built just for parsing code for Emacs in the same way cscope can not match the integration of Visual Studio's C# parser in Visual Studio.
I am arguing against the claim that a monolithic app like Emacs that bundles a specific tool is somehow qualitatively superior to any other tool which does not bundle a specific tool.
> But by its design it can not look for headers in appropriate locations
I think that's a perfectly valid design. I would rather want to spend 10 seconds adding a path to my project's config file than spend an eternity with just ctags. :-)
> Also it can not parse partially erroneous code.
Of course it can. Clang recovers from partially invalid code just fine.
For example, if I do something like "typedef enum { a, b, 3 } foo bar;" (constituting two syntax errors), it will still correctly autocomplete "foo" as well as its values, even though the type is strictly incomplete.
Emacs is a Lisp virtual machine and someone happens to have implemented da rather splendid text editor in it. Claiming that Emacs is monolithic is about as meaningful as calling the assorted programs that make up a Unix environment monolithic.
I agree, especially after witnessing TextMate go stale and TextMate2 start to follow the Duke Nukem Forever release schedule. When I see a project like IntelliJ, I'm confident they will be around awhile. Looking at TextMate and SublimeText... I'm a little hesitant. The development muscle doesn't appear very robust. If a lead developer (or the only developer) gets hit by a bus is the project going to disappear?
Unless people are going to step up and take the lead, being open source means nothing. If you want some assurance in this area it should be:
1) project is open source AND 2) project has a HUGE community AND 3) there are > 2-3 key developers
(I added (2) because even hugely successful open source projects where abandoned and left in the cold when most members of the core team decided to try something different. Like, how, D (the language) was abandoned for D2 (the second, different implementation).
The TextMate story everybody knows, it was good at first but got stale with no updates. I feel Sublime Text is fantastic, but after reading some article on Janus (https://github.com/carlhuda/janus) I switched over to MacVim.
After fiddling around with Vim for a while I can honestly say I'll need some serious convincing to switch to another editor. I've always stayed away from Vim except through occasional need for text editing through SSH or something, because out of the box it doesn't feel quite right. But after Janus sets up some sane defaults it feels great, and after putting a few hours in to learn all the shortcuts and study plugins I have never felt as productive.
I feel like Janus is sort of training wheels though cause it has a lot of plugins I don't use etc, but it's great to start and as I use Vim more I reckon I will start to manage my own .vimrc.
P.S., bcvi is so awesome.
I've made my own fork (https://github.com/darthdeus/janus) and basically removed 90% of the default plugins and settings and repalced them with my own, but I still use it for the Rake task and nice directory structure.
There is too much accredited awesomeness in Emacs (and to a somewhat lesser extent, Vim), to be overthrown by a newcomer. That said, Sublime Text is very worthy competition and given a few years, it might actually live up to those two dinosaurs.
Edit: I suppose people keep rediscovering these tools because even if they use vim, they often times insist on running it as a stand-alone GUI application, rather than in a terminal emulatir where the built-in task switching/multitasking makes it very easy to run complex shell commands, move files around, use your VCS and switch back to your editor. Another benefit is that now you can have the exact same work environment over ssh as locally.
Second, grep is not comparable, it's a different tool. For instance, if you would want to open the openCorpus function in the file MainWindow.cpp, in Sublime you'd just type "MWcp@opC", and you are there. While typing the pane and window dynamically update, allowing you to narrow down the 'search space' quickly.
Grep is for searching for text strings in files in the shell or shell scripts. Sublime's Goto Anything is for searching files and symbols in a text editor.
Edit: I like and use both vim and ST2, but neither grep, ctags, nor Peepopen provide the smooth experience of 'Goto Anything'. Of course, conversely vim also has many things to like over ST2 (such as modeful editing that is definitely better than ST2's Vintage).
I still use grep a lot while using ST2, but I use it for other purposes.
In Bash, you can do incremental (find as you type) history search with Ctrl+R. Something analogous for grep would be fantastic. Displaying more than one result at a time would also be great.
Another thing that grep/find lacks is a index that could make large fuzzy searches faster, but clearly that can be added too.
In fact, thinking about it now, they're quite different. The thing that grep excels at can't even be done easily (that I know of) in ST2: "I'm looking for this function called xyz, but I don't remember which file in this directory it's in."
Yeah. And a car is called a horse carriage. Why do we keep rediscovering tools that have existed for such a long time? (facepalm)
Grep does not:
1) know about the scope of the project, i.e what files to search, without instructed so specifically.
2) have knowledge of code structure (methods, classes, etc). So "fuzzy" here means just using regex.
3) does not know how to present you with the results in a way that you can open quickly in tabs, etc.
There's a plugin for SublimeText that supposedly imports the same autocomplete engine that Komodo uses. In my experience, however, it was slow, rarely worked right, and was actively broken for CSS autocompletes (which I also need frequently).
So it's back to Komodo Edit for me, at least until SublimeText gets its autocomplete act together. Which is a shame because I really liked ST as an editor.
If you're a touch-typist and you become proficient in vim, the friction between thinking about an edit and it materializing on the screen in front of you is reduced. I think 'whoops, need a comma there', my hands move around a little without thinking and the edits done. Contrast this with move hand to mouse, click where you want to edit, hit backspace, type in new character.
IME this is not necessarily faster, just a lot more comfortable once you get used to it.
A lot of comments will say 'you can have vi-mode in <other editor>' but I've yet to see an implementation that covers the entirety of normal mode _and_ supports custom remaps, and even then the mappings would need an interface to its plugins before it approaches a vim-like environment.
Vim plugins obviously don't work, but there is a world of Emacs libraries and you can now extend your editor in lisp.
There are still some inconstancies that bother me (e.g. special buffers that don't respect vim shortcuts), but overall I'm happy.
I don't know if I'd call Vim overly-opinionated. It's a legitimately incredible way to work with text.
(I know you can use home/end or ctrl to jump over words, however often these aren't always applicable and often still need visual feedback)
In vim it's significantly easier to jump to the desired point on the line with fewer key strokes and no need for a visual feedback loop.
In short; it's not the fact you can use the keyboard to navigate, rather it's the fact that you can navigate efficiently with the keyboard without having to think about the position of the cursor.
Which makes vim faster, but doesn't mean one needs to reach for a mouse; secondly, what touch typist isn't already watching what he's typing? Requiring visual feedback is hardly slow.
> In vim it's significantly easier to jump to the desired point on the line with fewer key strokes and no need for a visual feedback loop.
I'm aware of that, but that's not the argument you made. You said you didn't have to reach for the mouse, well, neither do any of the other editors.
> In short; it's not the fact you can use the keyboard to navigate, rather it's the fact that you can navigate efficiently with the keyboard without having to think about the position of the cursor.
While true, you overestimate how much other editors make you think about the cursor as well. Our muscle memory works just as well as yours and though vim gives you more options to exploit it, it's not as if other editors don't offer anything other than visual and a mouse.
Yes it is. You can go seven or eight keystrokes in vim recording a macro without any feedback whatsoever, and still end up with a wickedly powerful edit.
> I'm aware of that, but that's not the argument you made. You said you didn't have to reach for the mouse, well, neither do any of the other editors.
No I didn't. I simply said contrast that to moving your mouse. You could also contrast it to ctrl+right arrowing to the word on the line but in vim thats just `5w` (where five is the number of words along the line) in normal mode. It still requires less cognitive and physical effort. You could also contrast it to the built-in readline ctrl+ shortcuts and it would still be less keystrokes.
> While true, you overestimate how much other editors make you think about the cursor as well.
No I really don't. I wasn't magically born with vim superpowers. Like everyone else I started with a regular text editor and worked my way to vim proficiency. I became proficient with eclipse, crimson editor and quite a few others before deciding that vim was what I wanted to invest in long term.
> Our muscle memory works just as well as yours and though vim gives you more options to exploit it, it's not as if other editors don't offer anything other than visual and a mouse.
Very well, good luck to you with your other editors. I seriously think you should use whatever you feel most comfortable with.
Take this example line of code:
#define test "Some magical string."
f"ci"
WgUe
Vim is absolutely awesome, however it is but one way of editing text. Other methods have their own merits and incorporating their styles in your workflow will make you more proficient in the long run even if you eventually come back to Vim.
When you really know a fundamental text editor, that sensation of helplessness gets worse and worse when you can't use the shortcuts that are burned into your fingers.
If you don't know what I'm talking about, I suggest reading the StackOverflow answer "Your problem with Vim is that you don't grok vi."
I spend 95% of each day (not just my 8-5 - 95% of my time on a computer at all) in vim. The rest is in firefox or in a console briefly to tell it to run my tests. I code all day every day, and I quite enjoy it.
Today, I had a 7 hour meeting with a customer to spec out a new project. I had to put together mockups in balsamiq. On a mac (I'm a linux user). My level of discomfort was extremely high, eclipsed only by the fact that since a customer was there I couldn't take to just cursing like a sailor.
When you keep your hands on the home row for an entire day and then all of the sudden you have multitouch swipe gestures and clickie-scrollie touchpads and home keys that don't go home and delete keys that delete the wrong direction and inadequate terminal emulators, HOLY CRAP IS IT LIKE MINI-DYING.
That's all. I just completely feel you.
On my laptop, it's just fn+arrow for home, end, and page up/down, and my pinky is usually right there anyway for the control and meta keys.
Might be worth a try.
It does not support tables. You can not reorder entries. It does not support code blocks. You can fold, but you can not narrow (i.e. all headlines stay there, but content is folded away). Your favorite keyboard shortcuts are not there (though you can change that easily).
As much as I like Sublime Text, I am more productive in Emacs.
I've only been using ST2 for a few weeks on a Python project, but I feel that the end result is better for me than trying to patch together a chain of vim plugins. I gladly give up a few of the more esoteric vim features for the integrated project editing features of ST2.
Right, I just wanted to point out that it's not a very vim-compatible vim mode so people aren't surprised if they try it out.
Can. We. Stop. Posting. About. Fng. Text. Editors.
Please.
Imagine a room where you teleport in computer greats (in no order of importance, and I am probably forgetting tons of worthy people in my pang of internet angst) such as Gates, Torvalds, Ritchie, Thompson, von Neumann, Knuth, Turing, Carmack, ..., Joy, Berners-Lee, Babbage, Stroustrup, Dijkstra, Norvig, Moore, Noyce. I don't think these guys would start talking about text editing, so why should we?
Because we want to, that's why.
If you don't want to, feel free to ignore it.