I’ve been an avid Emacs user since college. I used it (along with LaTeX) to write, edit, and publish all my essays and theses. It was my FTP client, my mail reader, and, on occasion, my browser. I’ve used it to write web pages, screen plays, comic books, and every non-cocoa program I’ve ever compiled. Seeing Emacs on the command line was what convinced me OS X was a good idea. Finding a carbon port of it was a prerequisite of my moving to a Mac.
After all these years together, why am I now unceremoniously dumping Emacs without so much as a small redeeming twinge of guilt? It’s all because of this spunky little editor called TextMate. With all the love I have for Emacs, making the move to TextMate is still a no-brainer. Why? Two simple facts:
Down With C-x!
There are 101 keys on your average keyboard. The number of commands in Emacs is some value exponentially greater than this. So how does Emacs let you enter all those commands? Through prefix keys. Most of Emacs’s interesting commands take more than one set of keystrokes to access — first you type a prefix and then you type the actual command. For example, to open a file, you have to press ctrl-x and then ctrl-f. Even exiting Emacs takes multiple keys: ctrl-x and then ctrl-c. Remembering all these combinations of key presses is no easy feat. And actually typing them all leads to worn-out keyboards, RSI, and tears.
The best thing TextMate has going for it is its lack of this “feature”. No prefix keys! Every command in TextMate is accessible with a single key combination. Does that mean TextMate has fewer commands to offer than Emacs? Not at all! TextMate is just smarter about how it uses them.
The idea is so simple that it borders on genius. Every function in TextMate is bound not only to a key combination, but also to a context. cmd-R may reload the current browser when editing an HTML document, but it compiles and runs your program when editing ObjC files. Depending on the context (which file is loaded), the same key combination (cmd-R) performs different functions.
So far, this is not new — Emacs supports something akin to this using hooks to load minor modes for certain file extensions. But TextMate makes it revolutionary by increasing granularity. Not only are key combinations sensitive to what types of files are loaded, they are also aware of language grammar.
Imagine if, when writing code, your quote key inserts quotes normally within the source, but inserts escaped quotes when pressed inside a string? Or what if Cmd-I inserts a class template when in a java file, but then inserts a method template when pressed inside a class? And what if this same command prints an if() block when used inside a method! That’s the type of smarts TextMate has going on under the hood.
No LISP))))!
Don’t get me wrong, being fluent in a programing language from 1958 gets me plenty of trim at parties. But apart from its outdated syntax and the fact that Emacs is the only reason I ever have to dust off my lambda calculus hat anymore, Lisp is just not well-suited to the task of munging text. And what do you to all day in a text editor? Munge text! So why use Lisp as the backbone of your editor when a modern scripting language like, say, perl makes so much more sense?
But hey! Why limit yourself to perl? OS X ships with a plethora of scripting environments including bash, ruby, python, and others. Each has its own subtle strengths and weaknesses. TextMate lets you use all of these languages (and any other script interpreters or commands you can call from a shell) to build powerful text-manipulating macros. And it lets you do this all through its visual and highly-organized “Bundle Editor” so you don’t have to worry about messy include paths or dependencies.
Emacs, more often than not, struggles to be its own operating system oddly embedded inside of unix. TextMate, on the other hand, is a text editor that elegantly embeds unix functionality with as much HIG chrome as you please. The result is more focused and friendly than the Emacs/Lisp system, and yet sacrifices very little of the flexibility Emacs is known for (at least when it comes to editing text).
But don’t take my word for it. Check out some of the screencasts that show off what TextMate can do.
I too have recently forgone Emacs (specifically XEmacs) in favor of TextMate. I still have a hard time occasionally (save is NOT c-x c-s anymore!), but I find I don't miss much about it. I still use Emacs in ssh sessions for editing, but that's about it.
TextMate is simply fantastic and I wouldn't want to go back. Sorry Emacs.
TextMate isn't free, which is a deal-killer for me. Granted, I've not used Emacs much - JEdit for programming stuff, TeXShop for everything else.
TextMate has an awful lot going for it; for one thing, it just looks and feels like an OS X application while, say, BBEdit still seems like a holdover from System 7. That said, TextMate is *pathetically* slow at doing search and replace in a large file (say, 2000 lines of a CSV document). That's the only reason I launch BBEdit these days, and I hope the TextMate guys fix it soon!
TextMate is only €39 (about $50 USD). Big whoop. It's a great text editor, and great text editors usually run a lot more (i.e. BBEdit: $99). I'll be buying TextMate next time I get paid (whenever that is). It's that good.
I bought textmate, but I routinely use emacs.
The main drawback for Textmate for me is that it doesn't have split screen mode. I use this all the time in emacs, frequently viewing 3 or 4 files, or two different parts of the same file. Forget split screen, you cannot open two windows on the same file in Textmate no matter what you do.
A lesser drawback, perhaps owing to lack of experience, is that Textmate generally expects me to use the mouse too much. I can't create new folders, delete files, run rake, or copy from a man page without using the mouse, and switching to another program.
With emacs, my hands never need to leave the keyboard.
Textmate generally expects me to use the mouse too much.
Though I have to point out that TextMate does not suffer from the biggest failing of all other cocoa text views: TM allows you to open up a context menu with a keyboard shortcut (opt-F2 by default, though you can, of course, change that in KeyBindings.dict). One of my biggest pet peeves is that NSTextField/View will highlight spelling errors as you type, but provides you with no way to correct the errors short of picking up your mouse. Not a problem with TM. Just move the carrot over the word and opt-F2. The contextual menu pops up with spelling suggestions at the very top.
I've been a Emacs user for quite a while and tried loads of editors on the Mac until in around october last year I've found TextMate. I think it is absolutly the best editor around!
And people having trouble with the price... come on, you've bought a Mac, surely you have another 50 bucks to spare to get the most out of it!
I second Ray's comment about TextMate's split screen, though, as far as I can tell, this is a on the to do list, as it's often requested.
TextWrangler and BBEdit both have split views, however, they only allow split views of the same file which is only partly useful. In Vim I'm frequently needing to edit one file while referring to/copy and pasting from another file in another view. I also used jEdit (which has split views allowing different files to be loaded) until it's lack of speed encouraged me to learn Vim.
One thing I get so used to in Vim, that I forget about when editing text in any other application, is it's almost amazing auto-completion (I don't mean code-completion which it also has, I mean it's ability to be aware of almost any word available in it's open buffers). I sometimes find myself hitting tab while in Mail.app expecting it to auto-complete!
When testing out other text editors I generally start by checking for the bigger features like split views, folding, abbreviations, etc, but I nearly always forget about auto-completion until I start typing. After that I realise that I would be typing a whole lot more than I would be in Vim.
TM has a similar completion feature. On the down side, it only looks at the current document for possible completions. It does do some pretty cool magic where the completion list is sorted by distance from the insertion point, though. It's bound to esc by default, but is one of those that can be modified in KeyBindings.dict.
usually i don't shell out money for programms with a free alternative easy. but with textmate it took me 2 hours after the trial-period ran out. if you earn money with the work you do with a programm and it saves you some time you just have to think about what your time is worth.
Vim just keeps getting better and better. Version 7.0 came out last week, and supports tabbed editing among many other things. Most of the things you can do globally to a single file, you can (at your discretion) do to every tab.
Being able to type gvim -p *.ms and have my entire manual open up before me is soooo nice.
Ever notice that good old TextEdit comes with many Emacs command-key equivalents built right in?
Imagine if, when writing code, your quote key inserts quotes normally within the source, but inserts escaped quotes when pressed inside a string? Or what if Cmd-I inserts a class template when in a java file, but then inserts a method template when pressed inside a class? And what if this same command prints an if() block when used inside a method! That's the type of smarts TextMate has going on under the hood.
I don't mean to be an Emacs Evangelist Zealot kind of a person, but Emacs does do that. In latex mode, if you type the double quotes at the beginning of a quote, it puts the `` and at the end it puts the''. I'm no elisp wizard, but I imagine it would be relatively easy to have it bind Cmd-I to insert all those different things if you wanted it too, as well.
Besides, haven't you heard? Lisp is making a comeback. ;)
"being fluent in a programing language from 1958 gets me plenty of trim at parties"
Unbelievable.
Emacs does do that.
Perfectly true and fair. The difference is that Emacs does not evaluate which command to run based on context, the context must be intuited by the command. I don't say this in any way to belittle Emacs, but rather to highlight the brilliance of TextMate.
An example: In Emacs, for the quote key to do wild and magical stuff when pressed within the context of the string, the command bound to the quote key must first check to see if the insertion point is within a string. So the standard command insert-quote (I'm making up names here) must be rewritten to look for " string boundaries. Let's say this new command is called escape-quote-in-stiring. This new command gets bound to the quote key and everyone is happy.
But now lets say you're working in LaTeX, and you want the quote key to insert `` and'' outside of a string and ` and ' when inside of the string. We'll call this electric-insert-smart-latex-quote or something. Only one command can be bound to the quote key at a time. You cannot overload it even though you would use the different commands in definably different circumstances. If you wanted the functionality of both escape-quote-in-stiring and electric-insert-smart-latex-quote bound to your quote key in your LaTeX document, you would have to write one monolithic function combining the two (electrically-insert-escape-or-smart-quote-depending?).
Now look at the TextMate way. "This string" would have a context of string.quoted.double and ``this string'' would have a context of string.quoted.double.latex. When the quote key is pressed, it asks "what command bound to me most specifically matches the current context?" and runs it. Instead of having to write one monolithic function that implements exhaustive logic in an attempt to handle all possible scenarios, you only have to write a bunch of focused functions that deal specifically with the single scenario handed to them. Much more modular. Much easier to maintain.
The end result? Anytime I pressed a key in an Emacs mode that didn't do exactly what I thought it should, I had to do an elaborate cost/benifit analysis to determine if it was worth digging into and modifying to suit my tastes. More often than not, I didn't bother. TextMate makes it so effortless, I'd have to be incurably lazy not to make a change. As a result, I feel much more at home in TM after just a few months of using it than I ever did in Emacs.
> And actually typing them all leads to worn-out keyboards, RSI, and tears.
This is why people use Viper mode :-)
Hi. I thot i'd pipe up and mention you make yerself look a bit like an ass saying lisp has an outdated syntax and throwing spurious parens around.
I also noticed people say textmate isn't free. I suspect they mean it costs them their freedom, not their money.
Happy editing folks.
Well I wouldn't wish to be quite as rude as shawn but I also found many of the assertions in this article quite mind-boggling ("Lisp is just not well-suited to the task of munging text.", for example).
"The difference is that Emacs does not evaluate which command to run based on context, the context must be intuited by the command. I don't say this in any way to belittle Emacs, but rather to highlight the brilliance of TextMate."
It is not true that the "context must be intuited by the command" (see below). Even if it were, that's just one tiny aspect of (at least in Emacs' case) an enormously complex and powerful editor. If you prefer a simpler/different editor, that's fine but this short review doesn't come across as a celebration of the good things about TextMate anyway: if Emacs were the Taj Mahal and TextMate the Great Pyramid, it is a wholesale condemnation of the Taj Mahal based on wrongly perceived deficiencies in the design of its car park.
"An example: In Emacs, for the quote key to do wild and magical stuff when pressed within the context of the string, the command bound to the quote key must first check to see if the insertion point is within a string."
I'd expect most of the time that would be just fine but to get the brilliant TextMate behaviour, if you really need or want it, you could use a regexp to set overlays to provide the context, setting the overlay keymap properties accordingly. You'd then want to add a hook to 'after-change-functions' to dynamically update/add/delete your overlays near any changes. I expect this mechanism (or something like it) is in use in lots of stuff already written and though it's not something that'd be difficult for an Emacs 'power user' to ad hoc, perhaps it would be nice to make it more easily available and I believe Toby Cubitt's work-in-progress, AutoOverlays, will make it possible for someone who knows only regexps to do just that (and much more).
I also found many of the assertions in this article quite mind-boggling ("Lisp is just not well-suited to the task of munging text.", for example).
If you think it's easier to reorder/replace/substitute/regex/whatever strings in Lisp than in perl, I salute you. You're clearly much smarter than this humble author. I would submit to you, though, that to do so you'd have to take advantage of special Lisp macros and functions that are unique to Emacs. And this — not its comparative ease of use — is why I call it ill-suited to the tasks commonly performed by a text editor. For all intents and purposes, the custom functions Lisp relies on make it a proprietary macro language of whatever project it's tied to (in this case, Emacs) that happens to use Lisp syntax. In fact, if you go out and buy a big book on Lisp and read it cover to cover, you'll still have no idea how to write your own custom macro in Emacs. You'll have to buy a book on Emac Lisp (that is to say, Lisp with Emacs functions) in order to get started.
And let's be clear: I'm not picking on Lisp, per se. The fact that Lisp relies on libraries is not its fault. It's just a side-effect of it being a low-level language. The same could be said of C, C++, etc. I'm not picking on Lisp, I'm picking on the fact that Emacs uses a low-level language like Lisp for its macros. That made a lot of sense at the time, no doubt. But now that we have higher-level languages like perl, ruby, etc. and fast computers that make the abstraction of these languages invisible to the average user, it's a joy to be able to write macros in them because they allow me to do the same job in less code with a common set of functions.
I'd expect most of the time that would be just fine but to get the brilliant TextMate behaviour, if you really need or want it, you could...
Again, I'm not claiming this isn't possible to emulate in Emacs. I'm claiming that, to make that happen, you'd have to do all the non-trivial things you go on to describe in your paragraph. And even then, it would be a fragile and hackish solution. Perhaps AutoOverlays will clear this up? Maybe. But you mention, it's a work in progress. TextMate has this functionality built in now.
And do not overlook the mention I gave to TM's Bundle Editor. This is vitally important to making TM more manageable than Emacs. The documentation to AutoOverlays is obscure and incomplete, so I can't say for sure. But I'm guessing configuring it would require hacking my already bloated .emacs file, right? Compare that with TM's clean, visual, intuitive, integrated interface for managing macros, and you'll see that even an ideal AutoOverlays implementation leaves Emacs with ground to cover.
But let's put all that aside and assume a flawless, better-than-expected version of AutoOverlays is bundled with Emacs tomorrow. Do you think that will suddenly spell the end of prefix key? Do you honestly believe that gnu will make C-c the new key to exit emacs and C-f the new key to open a file? Sure, maybe I could configure my new AutoOverlays to override this vestigial behavior, but then it's back to hacking in my .emacs file... maybe for hours given all the prefix combinations native to Emacs.
if Emacs were the Taj Mahal ... it is a wholesale condemnation of the Taj Mahal based on wrongly perceived deficiencies in the design of its car park.
I would say it's a condemnation of Emacs because a text editor shouldn't try to be the 8th wonder of the world. The Taj Mahal looks fabulous. But if I'm looking to rent a flat, I'd steer clear. Can you imagine what it must cost to heat?
i agree that textmate is a really nice editor and much propably the best native *cocoa* based one out there. OTOH i see its main advantage over emacs in its speed (even more for quick editing tasks) and better system integration. as an *editing environment* emacs (and also vim fwiw) still is far superior -- at least for me. say "project management", say "syntax support" (the one in textmate *does* have its technical limits -- afaik it does *no* parsing but only regexp, mind you. so much for upmentioned "grammar"...), say "adaptability", say "outlandish strange stuff no one but me might ever need", whatever.
btw, you can easily use whatever scripting language you like for text processing in emacs or vim just as in textmate. and lisp (which has "slightly" evolved since 1958) not suited for text processing? oh, that's propably why it is still one of the most used tools in computational linguistics. >;-> come on! i'm *very* far from being a zealot, but some of your statements make me laugh just for the lack of insight.
The difference is that Emacs does not evaluate which command to run based on context, the context must be intuited by the command.
not necessarily (btw, take a look at ecb which does *real* parsing): make emacs aware of the context on a global scale (or at least within the respective mode) as a whole and rebind your electric-insert-whatever macros to the keys you like when the context changes by hooking e.g. into the cursor positioning code. tadaa! :-) --> modular, lean, well encapsulated, reusable, non-monolithic, whatever you desire ...
After 20+ years of ex and vi (I never liked nor switched to emacs), I started using mate (TextMate's command line alias or link) rather than vi. It's really good.
I can't bring myself to move away from TextWrangler until there's a file compare feature that's at least as good. TW 2.2+ has the best file comparison mechanism I've seen, bar none.
I'm sure TextMate is a nice editor (I don't have a Mac, so I can't judge), but some of your statements are downright retarded, and show that you know very little about programming languages. Lisp is a "low-level language" relative to Perl and Ruby? What kind of crack are you smoking? Lisp is the original high-level language, which is why it's used for artificial intelligence applications (I don't think Perl and Ruby have much traction in that domain). Now, emacs-lisp *is* a very outdated lisp (Common Lisp and Scheme are much more modern), but that doesn't mean it isn't powerful or high-level. RMS has stated his intention to change emacs to use Scheme instead of elisp, but nobody is holding their breath. Anyway, it may well be that TextMate has a better editing model than emacs; if so, good for it. All that means is that other editors will be playing catch-up for a while (and maybe emacs won't be able to make the transition). But don't just spout off nonsense.
some of your statements are downright retarded, and show that you know very little about programming languages
Maybe I'll retitle this (year old?!) post to read "TextMate made me give up Emacs even though I'm retarded where programming languages are concerned," and we'll call it a day? :-)
Lisp, C, et al. don't have built-in text processing capabilities. perl, ruby, etc, do. What's the proper academic name for this difference between these languages? That name, whatever it is, is what makes me like the latter over the former with respect to writing text editor extensions. You can call it "fuzzymoldism" for all that I care. I'll still prefer writing string manipulation code in ruby rather than lisp.