Working on It (TextMate)(blog.macromates.com)
blog.macromates.com
Working on It (TextMate)
http://blog.macromates.com/2009/working-on-it/
108 comments
There are actually a few nagging bugs in Textmate which require fundamental changes to address. Allan also seems to be somewhat of a purist, given this rewrite and the fact that he can't get a simple blog post "good enough" to put out there. He likely considers it a good thing because he wants to do it.
Code very much does get stale, at least to the developer looking at it every single day, and sooner or later almost everybody wants to throw everything out and start over. We generally don't do that because we can't justify it in terms of the business, but when you're a solo developer I suppose you can do whatever the hell you want ;)
Code very much does get stale, at least to the developer looking at it every single day, and sooner or later almost everybody wants to throw everything out and start over. We generally don't do that because we can't justify it in terms of the business, but when you're a solo developer I suppose you can do whatever the hell you want ;)
Yup, I think you're probably right.
We generally don't do that because we can't justify it in terms of the business
True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.
And to be honest, unless Textmate 2 is significantly worse than 1.x, I'll buy an upgrade license.
We generally don't do that because we can't justify it in terms of the business
True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.
And to be honest, unless Textmate 2 is significantly worse than 1.x, I'll buy an upgrade license.
because you throw out years of real-world testing and bugfixes
Very true, but you also get to trade in on the experience and information gleaned from the use and development of a product over many years. I think it is safe to say that Allan knows far more about Textmate now than he did when he started it, and perhaps that insight has allowed him to bring some significant improvements to the text editor as a whole.
Maybe I'm just biased; I tend to rewrite stuff before I've even written it once.
Very true, but you also get to trade in on the experience and information gleaned from the use and development of a product over many years. I think it is safe to say that Allan knows far more about Textmate now than he did when he started it, and perhaps that insight has allowed him to bring some significant improvements to the text editor as a whole.
Maybe I'm just biased; I tend to rewrite stuff before I've even written it once.
True, but Joel's point is that a rewrite can actually be bad for the code not just the business, because you throw out years of real-world testing and bugfixes.
I think that applies on project with multiple developers and whose developers are not in the company anymore. When it's a solo developer, he still has the experience and doesn't lose so much from throwing out the code
I think that applies on project with multiple developers and whose developers are not in the company anymore. When it's a solo developer, he still has the experience and doesn't lose so much from throwing out the code
There's truthyness in that statement... but I've re-written code from years before that I wrote myself; it's easy to forget all corner cases you handled in old code. It forces you to take a step back from your new, clean, way to solve the problem and make sure it really does cover those forgotten cases too. The added uncertainty really hurts the predictability of a re-write.
That's why you should write automated tests for your corner cases (and of course not only the corner cases). If all corner cases you knew about are properly tested, your rewrite should function properly.
A little offtopic, but I would say this is the reason that vigilantly commenting your code is essential, especially for a one man shop.
I've learned this the hard way enough times to make it stick to the point now that even when I'm just writing regular, mundane CSS, I make sure to comment in every workaround I write, no matter how routine. It takes longer, but it's worth saving me from myself.
I've learned this the hard way enough times to make it stick to the point now that even when I'm just writing regular, mundane CSS, I make sure to comment in every workaround I write, no matter how routine. It takes longer, but it's worth saving me from myself.
Let me counter with Fred Brooks' "Build one to throw away."
Even just the fact that TextMate is a one-man project is good reason to think that Odgaard knows best whether a rewrite was appropriate.
Even just the fact that TextMate is a one-man project is good reason to think that Odgaard knows best whether a rewrite was appropriate.
I remember that Textmate 1.0 was partially driven by DHH - I wonder to what extent that external influence had on Odgaard.
Do you have a source for that?
From http://www.loudthinking.com/arc/000270.html:
Disclaimer: I know the programmer. I've been pretty heavily involved with the development process by helping to determine, prioritize, and test features. I have no financial involvement, however. All my work and hype are small tributes to the awesome archievement that is TextMate. I feel blessed to be able to help it gain traction
Disclaimer: I know the programmer. I've been pretty heavily involved with the development process by helping to determine, prioritize, and test features. I have no financial involvement, however. All my work and hype are small tributes to the awesome archievement that is TextMate. I feel blessed to be able to help it gain traction
Brook's isn't always right. I think that quote is one example.
I think so long as 2.0 maintains backwards-compatibility with 1.x (possibly include 1.x with the 2.0 app?), and it doesn't hamper at all from the user experience, a re-write might be a good thing. Or, allow easy plug-in migration from 1.x to 2.x (kinda like what Python did going from 2.0 -> 3.0).
There are plenty of examples where complete re-writes, or partial re-writes, have led to bad things. Windows Vista and Winamp 3.0 come to mind.
Good examples include Mac OS X, Linux 2.x (I believe this was a major re-write over 1.x - could be wrong as my Linux history isn't up to buff). Starcraft was completely re-written mid-development (originally it was built on the Warcraft II engine, which didn't scale).
I would tend to agree with you, though, that major re-writes typically yield worse things. But, that depends a lot on the product, its audience, and the developer. Perhaps Allan, who has likely been writing code for a very long time, knows of some bottlenecks and what-not that he feels should be incorporated into 2.0, which necessitates a total re-write.
If worse comes to worse, the 2.0 codebase bombs and 1.x continues going on strong. That's exactly what happened to Winamp 2.0 when 3.0 came out.
And I should mention, to clarify any possible bias in my opinion, that I'm a very happy Textmate user. :)
There are plenty of examples where complete re-writes, or partial re-writes, have led to bad things. Windows Vista and Winamp 3.0 come to mind.
Good examples include Mac OS X, Linux 2.x (I believe this was a major re-write over 1.x - could be wrong as my Linux history isn't up to buff). Starcraft was completely re-written mid-development (originally it was built on the Warcraft II engine, which didn't scale).
I would tend to agree with you, though, that major re-writes typically yield worse things. But, that depends a lot on the product, its audience, and the developer. Perhaps Allan, who has likely been writing code for a very long time, knows of some bottlenecks and what-not that he feels should be incorporated into 2.0, which necessitates a total re-write.
If worse comes to worse, the 2.0 codebase bombs and 1.x continues going on strong. That's exactly what happened to Winamp 2.0 when 3.0 came out.
And I should mention, to clarify any possible bias in my opinion, that I'm a very happy Textmate user. :)
OS X wasn't a complete rewrite. It was a "Our rewrite is going to hell, lets buy a new OS to use." Go look up the history of Copland from Apple, its mildly interesting.
Its a rewrite in that they threw out nearly an entire codebase and built it on top of something different. If tomorrow Microsoft said "lets get rid of Vista and build something new on top of Ubuntu", I think it would be fair to call that new version of Windows a rewrite despite them not having written the underlying code. Also, lets not forget that a fair amount of work (understatement) went into Mac OS X post NeXT.
I think this stretches the definition of a rewrite a little beyond the point it should break.
OSX is more like a rebranded descendant of NextStep/OpenStep, just the same as a would-be Microsoft Windows 10 derived from FreeBSD code.
OSX is more like a rebranded descendant of NextStep/OpenStep, just the same as a would-be Microsoft Windows 10 derived from FreeBSD code.
"Windows Vista and Winamp 3.0 come to mind."
Vista is not a rewrite of XP - its a new bunch of kernel code grafted on top of the XP kernel, which is more or less the same as the 2000 kernel, which is an improved NT 4 kernel, which is more or less 3.5 with some stuff moved from user space into kernel space, giving a whole lot of stability problems due to low-quality driver software. It seems no full rewrite occurred between 3.1 and 7. The only rewrite I heard of was the one between the PDC 2003 video when Microsoft realized they would not be able to finish what they promised (managed code throughout the OS, the eye candy from the Longhorn concept video), threw a=out what they were doing and went back through a less ambitious route.
As far as rewrites go, Win7 seems more or less a rewrite of the Vista cruft that was added on top of the XP kernel.
Vista is not a rewrite of XP - its a new bunch of kernel code grafted on top of the XP kernel, which is more or less the same as the 2000 kernel, which is an improved NT 4 kernel, which is more or less 3.5 with some stuff moved from user space into kernel space, giving a whole lot of stability problems due to low-quality driver software. It seems no full rewrite occurred between 3.1 and 7. The only rewrite I heard of was the one between the PDC 2003 video when Microsoft realized they would not be able to finish what they promised (managed code throughout the OS, the eye candy from the Longhorn concept video), threw a=out what they were doing and went back through a less ambitious route.
As far as rewrites go, Win7 seems more or less a rewrite of the Vista cruft that was added on top of the XP kernel.
Windows Vista and Winamp 3.0 come to mind.
There's a big difference between these two examples. Vista was still developed by Microsoft but Winamp 3.0 was started after Nullsoft was acquired by AOL.
There's a big difference between these two examples. Vista was still developed by Microsoft but Winamp 3.0 was started after Nullsoft was acquired by AOL.
The wikipedia article mentioned that 2.0 and 3.0 was developed in parallel (http://en.wikipedia.org/wiki/Winamp#Winamp3). I'm not sure if that means if they were made by the same coders, however...
because sometimes you realize that in the beginning you thought that what you coded would suffice, but then users started coming up with feature requests/bug reports wanting more and you just can't do it without a rewrite, however big. like textmate not supporting non-fixed-width encodings, requiring any cjk user to use half-width fonts as a pretty annoying hack. i for one can't stand half-width fonts, so i just go with a different editor when i am working in more than one language.
and while that sounds like an incremental feature (and is), it looks like it's a nontrivial change among others to be done to textmate that 2.0 is aiming for.
if i had to wait this long to get proper cjk support (hopefully!), that alone to me justifies the long wait, and i wouldn't consider it to be a huge strategic error. that is, if this and more all happens with the launch of 2.0.
and while that sounds like an incremental feature (and is), it looks like it's a nontrivial change among others to be done to textmate that 2.0 is aiming for.
if i had to wait this long to get proper cjk support (hopefully!), that alone to me justifies the long wait, and i wouldn't consider it to be a huge strategic error. that is, if this and more all happens with the launch of 2.0.
Is it a fact that implementing fixed-width fonts actually requires a complete rewrite of all code and rethinking of the fundamental data structures? I think there's a pretty big gap between making a nontrivial change to an existing codebase and starting all over.
I certainly don't agree with Joel on everything, but I think he makes excellent points in the essay I linked above. I think every programmer maintaining a project hits a point where they want to rewrite everything. The code is full of hacks, the API is crufty, the requirements have evolved, etc. But that doesn't mean that such a rewrite is a good idea. And I bet we could all agree that a rewrite is not implicitly a good idea. All other things being equal old, tested code is better than new, untested code.
I certainly don't agree with Joel on everything, but I think he makes excellent points in the essay I linked above. I think every programmer maintaining a project hits a point where they want to rewrite everything. The code is full of hacks, the API is crufty, the requirements have evolved, etc. But that doesn't mean that such a rewrite is a good idea. And I bet we could all agree that a rewrite is not implicitly a good idea. All other things being equal old, tested code is better than new, untested code.
I don't disagree, but I can only assume Allan reached a point where maybe all the features/fixes to-be-implemented warranted a near-total rewrite as opposed to individually fixing or implementing them.
Plus, the CJK fixes in particular he's discussed literally now years ago were supposed to involve Core Text, which I believe was new to Leopard, which was then in turn a fairly new thing. Perhaps in addition to his shortsightedness/disinterest/whatever it may have been that he didn't consider that cjk would be an issue, new APIs and more made the idea of a rewrite more appealing.
Plus, the CJK fixes in particular he's discussed literally now years ago were supposed to involve Core Text, which I believe was new to Leopard, which was then in turn a fairly new thing. Perhaps in addition to his shortsightedness/disinterest/whatever it may have been that he didn't consider that cjk would be an issue, new APIs and more made the idea of a rewrite more appealing.
well, the reason a rewrite is bad is that it gives competitors time to produce a better product. in terms of text editors on Mac, nothing else is really that close, so it seems like Allan hasn't really lost out.
in terms of text editors on Mac, nothing else is really that close
I don't see that many textmate users dropping it for emacs any time in the near future. Yes, textmate was inspired by emacs, but it tends to appeal to a different crowd.
I did. It was actually TextMate that got me back into Emacs after all these years. I needed something at work on my not-a-Mac that was as good as TM. e and InType were close, but fell into the (sorry in advance for the cliche) uncanny valley, where any minor shortcoming relative to TM was doubly unsettling. It was actually easier to adjust to Emacs than to the also-rans.
Not emacs, but I dropped TextMate for Vim, and was very, very happy to do so. The stagnated development, the closed source and lack of portability, the annoying bugs etc. made it an easy choice.
but it tends to appeal to a different crowd.
People that know how to read?
People that know how to read?
The more I try using TextMate, the more I find myself using Aquamacs. There are some things that TM is clearly better at, but there are a lot of immature features:
- find in project is slow - window and buffer management - editing via SFTP (tho Aquamacs has horrible lag for me) - syntax highlighting crashes on really long lines and files - too many keyboard shortcuts... I often hit the wrong key and have it add a random code snippet to my JavaScript file (yes, this is probably configurable, but I expect good defaults from commercial apps)
- find in project is slow - window and buffer management - editing via SFTP (tho Aquamacs has horrible lag for me) - syntax highlighting crashes on really long lines and files - too many keyboard shortcuts... I often hit the wrong key and have it add a random code snippet to my JavaScript file (yes, this is probably configurable, but I expect good defaults from commercial apps)
All text editors are subsets of emacs... that doesn't make emacs more usable or productive though.
Emacs is extremely "productive" in the hands of a capable user. A "hacker", let's call him or her. "Usable"? Well, not in the hands of a beginner. If you want to just click a few things, Emacs is not for you. If, on the other hand, you live in your text editor all day long (you are, say, a programmer), what Emacs lacks in usability it makes up for 1000 times over in extensibility, flexibility, and ability to do pretty much anything you could imagine, with a bit of effort.
I didn't say it wasn't productive. I said "more productive".
The difference is setup overhead. If you discount the effort to get your environment dialed-in, then of course emacs will be the best choice. On the other hand I encourage you to consider that Emacs Lisp may not in fact be the best tool for all jobs.
I'm not sure why you put "productivity" and "usability" in quotes, or why you mention "beginners" and "want to just click a few things". We're talking about programmer tools here, so suggesting that a non-programmer couldn't use emacs is not really apropos.
The difference is setup overhead. If you discount the effort to get your environment dialed-in, then of course emacs will be the best choice. On the other hand I encourage you to consider that Emacs Lisp may not in fact be the best tool for all jobs.
I'm not sure why you put "productivity" and "usability" in quotes, or why you mention "beginners" and "want to just click a few things". We're talking about programmer tools here, so suggesting that a non-programmer couldn't use emacs is not really apropos.
Emacs is forever. In other words, 'dialed in' is a continuous process, which will keep happening no matter what language or environment is popular today.
I think at some point any piece of software requires a major rewrite (of course, when that point is depends). Whenever software is written, fundamental assumptions get made, and even the most forward thinking architects can't predict everything that will become possible or necessary. For a while, it is simply enough to build on top of what you currently have, but eventually the underlying architecture will no longer represent the main goals of the app. At this point, the spaghetti and hacks will far outnumber the well written aspects of an application and you will be spending most of your time trying to navigate the mess.
Again, that's not to say all software should be rewritten for every version. Mac OS X has been around for about 10 years and could easily go for another 10 with its current architecture. However, I think we can all agree that sometime between now and 100 years from now, something fundamental will probably have to change.
Again, that's not to say all software should be rewritten for every version. Mac OS X has been around for about 10 years and could easily go for another 10 with its current architecture. However, I think we can all agree that sometime between now and 100 years from now, something fundamental will probably have to change.
What do you think of Apple rewriting Finder in Cocoa? I'm happy about that.
How do you know you're happy with that?
Hasn't everyone tried the Snow Leopard beta?
I've tried it and am very happy with it. But even if you haven't, many people are still excited about it. A cocoa rewrite means much better performance and extensibility.
Now they just need to re-write iTunes in Cocoa (hopefully something they'll do for iTunes 9)
I've tried it and am very happy with it. But even if you haven't, many people are still excited about it. A cocoa rewrite means much better performance and extensibility.
Now they just need to re-write iTunes in Cocoa (hopefully something they'll do for iTunes 9)
"A cocoa rewrite means much better performance and extensibility."
Only if they bother to make it fast and extensible.
Only if they bother to make it fast and extensible.
Which they explained were 2 main focuses in the keynote. A Cocoa rewrite will make it faster out of the box.
I think his point is that it isn't Cocoa itself which makes the new version faster and more extensible: It's the rewriting process. The new codebase has presumably been better structured to be faster and more extensible.
As John Gruber has said "Cocoa is just an API. It is not some sort of magic technology where you just sprinkle a ton of square brackets in your source code and you instantly get a better UI." (http://daringfireball.net/linked/2008/10/30/cocoa-finder)
As John Gruber has said "Cocoa is just an API. It is not some sort of magic technology where you just sprinkle a ton of square brackets in your source code and you instantly get a better UI." (http://daringfireball.net/linked/2008/10/30/cocoa-finder)
I agree 100%, but a well written cocoa app is much easier to achieve than a carbon app (one reason why the Finder has been screwed up all these years).
But I agree, a rewrite with performance and accessibility in mind is what makes it faster, not cocoa itself (should've reworded that).
But I agree, a rewrite with performance and accessibility in mind is what makes it faster, not cocoa itself (should've reworded that).
If you have, you're breaking an NDA by talking about it.
I never signed an NDA, I guess I agreed to one when installing the software? I'm not a developer, the WWDC release is all over BitTorrent.
Look how many years it took them to finally do it though. Hell, there's practically nothing left to do...
Did they FTFF too, or did they just rewrite it? I have not tried Snow Leopard.
I think you mean "inherently" rather than "implicitly": Allan has been pretty explicit about why he considers a complete rewrite a good thing.
Assuming that's what you meant: I don't think anyone suggests that complete rewrites are inherently proper. It depends on a host of factors, and the pile of failed rewrites in the world is a testament to the risk involved.
In any case, examining what "people" are clamoring for is not necessarily the best way to make decisions. Before TextMate 1 had been released, no one was looking for anything quite like it. When you send tools into the world, it's impossible to tell before hand what will be done with them, and I don't think you should dismiss the introduction of substantial new features (so substantial that they couldn't be built on the previous architecture) with a hand-wave like "most people" not wanting something "totally different".
Assuming that's what you meant: I don't think anyone suggests that complete rewrites are inherently proper. It depends on a host of factors, and the pile of failed rewrites in the world is a testament to the risk involved.
In any case, examining what "people" are clamoring for is not necessarily the best way to make decisions. Before TextMate 1 had been released, no one was looking for anything quite like it. When you send tools into the world, it's impossible to tell before hand what will be done with them, and I don't think you should dismiss the introduction of substantial new features (so substantial that they couldn't be built on the previous architecture) with a hand-wave like "most people" not wanting something "totally different".
A surprisingly thoughtful post. This is a non-unknown genre—the stagnant software mea culpa—but I think he strikes a good and elegant tone. On the one hand, it's rare for a developer to acknowledge that they've been remiss in maintaining public contact, and even to enlist outside help for that specific purpose. But at the same time, he's obviously not at all concerned with letting actual releases of the software dry up while he methodically refurnishes the whole app. For a really hyped-up application like Textmate, whose users are going to be quite vocally clamoring for both their own pet features as well as beta and alpha releases ASAP, that too is impressive.
Of course, I've long since found my home in MacVim, so maybe I'm simply enjoying my lack of expectations from him.
Of course, I've long since found my home in MacVim, so maybe I'm simply enjoying my lack of expectations from him.
For a really hyped-up application like Textmate, whose users are going to be quite vocally clamoring for both their own pet features as well as beta and alpha
This is why open-source editors have made closed-source editors all but extinct. There are just too many things to do for one person, or even one group of people.
This is why open-source editors have made closed-source editors all but extinct. There are just too many things to do for one person, or even one group of people.
For those who want to buy an editor for MS Windows (besides the reliable warhorse UltraEdit), this may be interesting:
http://www.sublimetext.com/
I liked what I saw 18 months ago, in particular the overview pane, but the author seemed to let it ... rest. The website main pages still give that impression, but I just looked and the author is active in the forum and pushing out betas.
I liked what I saw 18 months ago, in particular the overview pane, but the author seemed to let it ... rest. The website main pages still give that impression, but I just looked and the author is active in the forum and pushing out betas.
all but extinct
Microsoft Visual Studio seems to be doing OK
Microsoft Visual Studio seems to be doing OK
yeah, but can you name many others?
Coda is doing well, and Espresso had a pretty big release recently.
Coda is doing well, and Espresso had a pretty big release recently.
This is an outlier, since the Windows stack is so closed in general. I think a large number of VS users use it because they are forced to by their environment choice (or employer).
I tend to think of editors like TextMate, emacs, and vim to be chosen by people who invest some thought into making the decision, rather than by people that are forced to use something for work.
I tend to think of editors like TextMate, emacs, and vim to be chosen by people who invest some thought into making the decision, rather than by people that are forced to use something for work.
Perhaps it's an outlier in that the language is more closed than most (and that this gives MS a pretty huge advantage over other IDE makers), but VS really is the best environment for developing .NET. That's why people pay for it, not because management forced it on them.
The question then is, "Why the closed .NET stack" and not Java or Mono.
> since the Windows stack is so closed in general
Huh? What about NetBeans or Eclipse? There is tons of open software for Windows.
Huh? What about NetBeans or Eclipse? There is tons of open software for Windows.
One example in a sea of corpses...
Xcode is doing decently well too... And TextMate or CSSEdit or Coda or Espresso or BBEdit...
The "Open source killed closed source" argument doesn't really apply to Mac OS X. Sure, there's Smultron or MacVim or Aquamacs, but they're not really the most popular of text editors (looking at GUI-based ones).
The "Open source killed closed source" argument doesn't really apply to Mac OS X. Sure, there's Smultron or MacVim or Aquamacs, but they're not really the most popular of text editors (looking at GUI-based ones).
On Windows, Zeus is alive and well - http://www.zeusedit.com
I reluctantly use textmate. If you can show me any open source editor that just works on OSX, I'll gladly use it (Closest I've found is jedit).
I just want a simple, easy to use, easy to learn, UI based editor with syntax highlighting.
I just want a simple, easy to use, easy to learn, UI based editor with syntax highlighting.
So what's wrong with jEdit? I've used it on Windows, OSX, and Linux and found it identical in each. It has highly customizable syntax highlighting, and is easy to learn. (Some seem to find the UI ugly, but I don't.)
I've tried to install it on latest OSX 10.5.7 a few times, can't get it to work at all. I used it happily on my old macbook, but no dice now :/
Maybe I should try harder.
I do like the way TextMate opens a directory tree and has it to the left or right of the edit pane, can jedit do that?
Maybe I should try harder.
I do like the way TextMate opens a directory tree and has it to the left or right of the edit pane, can jedit do that?
Yep. Integrated file browser, fairly powerful. Dockable wherever, or floating pane. Under Utilities.
In Allan's defense, he's come up with the first real advance in text editing for decades (his whole syntax scanning and bundle subsystems), and he deserves a chance to show what he can do as a second act. I expect great things.
What is the breakthrough in the syntax scanning?
I don't know that I can do justice to the idea, since I'm no bundle-writing expert, but see http://manual.macromates.com/en/language_grammars.html for the details.
The basic advance over something like an Emacs-Lisp package is that he built a declarative system (based on context-dependent regexps) for handling arbitrary languages, rather than making you write all the code to do so from scratch.
And he built things in such a way as to be able to handle languages nested inside other language contexts (e.g., Ruby inside HTML).
Couple that with a pretty powerful templating facility, and you have something that advances the state of the art.
I don't think anyone else has really taken as fresh a look at text editing for a long time.
The basic advance over something like an Emacs-Lisp package is that he built a declarative system (based on context-dependent regexps) for handling arbitrary languages, rather than making you write all the code to do so from scratch.
And he built things in such a way as to be able to handle languages nested inside other language contexts (e.g., Ruby inside HTML).
Couple that with a pretty powerful templating facility, and you have something that advances the state of the art.
I don't think anyone else has really taken as fresh a look at text editing for a long time.
rather than making you write all the code to do so from scratch
Emacs does not make you do this. (setf font-lock-keywords '(("some-regexp" . whatever-face-you-want-that-to-be) ...)). There are several other forms that font-lock understands, including custom functions that do highlighting.
Emacs also has something called the "syntax table", which allows you to declare what comments and string literals look like. Emacs can then use this information to syntax highlight those elements, and not do other syntax highlighting inside them.
cperl-mode uses this combination of features to correctly highlight nearly 99% of Perl constructions correctly. (Keep in mind that Perl and C++ have the dubious honor of not being parseable with a formal grammar, so it is somewhat impressive that syntax annotations + regexps is enough to do a good job.)
Emacs does not make you do this. (setf font-lock-keywords '(("some-regexp" . whatever-face-you-want-that-to-be) ...)). There are several other forms that font-lock understands, including custom functions that do highlighting.
Emacs also has something called the "syntax table", which allows you to declare what comments and string literals look like. Emacs can then use this information to syntax highlight those elements, and not do other syntax highlighting inside them.
cperl-mode uses this combination of features to correctly highlight nearly 99% of Perl constructions correctly. (Keep in mind that Perl and C++ have the dubious honor of not being parseable with a formal grammar, so it is somewhat impressive that syntax annotations + regexps is enough to do a good job.)
A little bit of meta-commentary.
I find it amusing that people are downmodding this post that contains correct information. There is no editorializing here; just information about how the syntax-highligting works, and my experience with working on a major mode for a very complicated language (using said tools).
If you must downmod, downmod the parent which contains untrue FUD.
I find it amusing that people are downmodding this post that contains correct information. There is no editorializing here; just information about how the syntax-highligting works, and my experience with working on a major mode for a very complicated language (using said tools).
If you must downmod, downmod the parent which contains untrue FUD.
Yes, I apologize for my sloppy statement.
I realize Emacs does a lot of the work for you. It's just that I've worked with some of these mode packages over the years and have been impressed with the complexity they embody and the size of the code involved.
Textmate seems to avoid most of that complexity with its declarative system, and still give you syntax highlighting and auto-indenting, etc.
I realize Emacs does a lot of the work for you. It's just that I've worked with some of these mode packages over the years and have been impressed with the complexity they embody and the size of the code involved.
Textmate seems to avoid most of that complexity with its declarative system, and still give you syntax highlighting and auto-indenting, etc.
This is mostly because authors can't resist the urge to also do something "interesting" in addition to "just" syntax highlighting. imenu support for example. (imenu is "tags without a tags table" for one file.)
If you look at cperl-mode, for example, syntax highlighting and indentation support is only a small part of its line count. The rest is things like auto-documentation of core features, including 100s of lines of documentation strings for Perl core functions.
If you look at cperl-mode, for example, syntax highlighting and indentation support is only a small part of its line count. The rest is things like auto-documentation of core features, including 100s of lines of documentation strings for Perl core functions.
That's very cool.
I will check how syntax highlighting is implemented in Emacs to check if something like this can be done and learn some Lisp in the process.
I keep hearing people state their love for TextMate but since I don run OSX and there is no Linux version, I am out of luck.
They could use their rewrite to make it compilable against GNUStep...
I will check how syntax highlighting is implemented in Emacs to check if something like this can be done and learn some Lisp in the process.
I keep hearing people state their love for TextMate but since I don run OSX and there is no Linux version, I am out of luck.
They could use their rewrite to make it compilable against GNUStep...
I keep hearing people state their love for TextMate but since I don run OSX and there is no Linux version, I am out of luck.
I would not worry too much about this. Assuming you are willing to use Google and edit your .emacs file, Emacs can do everything TextMate can. It also has the potential to do many things that TextMate can't. (I don't see Slime for TextMate.)
I would not worry too much about this. Assuming you are willing to use Google and edit your .emacs file, Emacs can do everything TextMate can. It also has the potential to do many things that TextMate can't. (I don't see Slime for TextMate.)
It's been (well, is in the process of being) done - http://redcareditor.com/
It's already useable, if you can deal with the pain of the installation process.
It's already useable, if you can deal with the pain of the installation process.
Hrm, maybe that explains why I've been annoyed with the syntax scanning. With really long lines or files, it seems to crash the app. This happens all the time when I am working with poorly formatted JSON fixture data.
I use TextMate every day. I hadn't noticed the lack of posts because for me, TextMate "Just Works(tm)". It is easily enhanced via python (or whatever your favorite language) through its bundle system so I have no need to depend on the developer to support my every whim. I'm glad he's working on TextMate 2 and starting to blog about it, but for me what I have works great!
You haven't run into crashes or been disappointed in its search feature?
I haven't. I use it every day, for a number of purposes from updating my blog to working on the Woobius codebase (in both Rails and Flex/AS3), and I haven't had any issues whatsoever. The global search-and-replace works great, too.
I'd quite like split-screen editing, that's my main bug-bear, but I've actually structured my use of TextMate around that - I basically just have several Textmate windows open. I've been meaning to switch to Emacs for that, but I suspect that managing buffers (and making sure they end up in the right pane) will take as much effort as dragging a few windows around.
I'd quite like split-screen editing, that's my main bug-bear, but I've actually structured my use of TextMate around that - I basically just have several Textmate windows open. I've been meaning to switch to Emacs for that, but I suspect that managing buffers (and making sure they end up in the right pane) will take as much effort as dragging a few windows around.
"but I suspect that managing buffers (and making sure they end up in the right pane) will take as much effort as dragging a few windows around."
I think you'd be surprised. In my experience I have a fixed set of windows (not os windows, but panes, as you called them), and easily and quickly switch between them with Iswitch-buffers: http://www.emacswiki.org/emacs/IswitchBuffers
this add-on gives you incremental-search to choose among open buffers, and usually it only takes a couple of keystrokes to get the one I want - so instead of moving the mouse around and clicking somewhere small and dragging things around, I am back in business after something like 'C-x b sh' - control-x, b to invoke iswitchb, and 'sh' to get me to my shell buffer...
I think you'd be surprised. In my experience I have a fixed set of windows (not os windows, but panes, as you called them), and easily and quickly switch between them with Iswitch-buffers: http://www.emacswiki.org/emacs/IswitchBuffers
this add-on gives you incremental-search to choose among open buffers, and usually it only takes a couple of keystrokes to get the one I want - so instead of moving the mouse around and clicking somewhere small and dragging things around, I am back in business after something like 'C-x b sh' - control-x, b to invoke iswitchb, and 'sh' to get me to my shell buffer...
The problem I think I'll have is not so much the actual switching of buffers, but making sure they end up in the right pane when first opened.
That's good — you've had better luck than I. It has crashed somewhat randomly from time to time for me, usually when I'm working with a lot of files or doing a search. Search works well for me, but it's sometimes slow and could be designed more effectively.
[deleted]
"Ack in Project" is so much better than the built-in search it's not even close.
Have you found a replacement for "jump to file"? Command+T is great until you have a lot of same-name files in different directories (it doesn't take the directory into account).
e.g. in a Django project it'd be common to have users/models.py, events/models.py, polls/models.py - you press Command+T and you can only search on models.py, if you type "pmod" you don't get polls/models.py. Highly annoying when hopping between files is so common.
e.g. in a Django project it'd be common to have users/models.py, events/models.py, polls/models.py - you press Command+T and you can only search on models.py, if you type "pmod" you don't get polls/models.py. Highly annoying when hopping between files is so common.
No - it crashes less than once a month on my system and I'm using the excellent Ack in Project mentioned by others instead of the built-in search. The Project Plus bundle also gives a nice for large projects but in general Ack is the only one I consider necessary.
Not much, but yeah search does brick out occasionally and TM must be restarted.
I'm not sure it matters any more. TextMate is a wonderful product and compared to other editors at its time of release it was AMAZING. But the developers lack of attention to the product (publicly at least) and the long wait time between the last public release has destroyed the lead TextMate had. These days the options are almost endless for text editors on OS X-many of them with all the great features from TextMate and encompassing all the great features requested for TextMate 2. Komodo Edit for example is free, cross platform, includes loads of language bundles, multiple tabs, remote editing (SFTP, FTP, SCP), scripting and code completion. MacVIM brings all the power of VIM to the OS X GUI.
I don't bear any ill will to this guy-I still think TextMate is a great product. But I think his slow movement has doomed the product in the long term.
Both MacVIM and Komodo Edit have been around for years, and haven't really changed much while Allan has been working on TextMate 2, so I can't see how that's relevant.
According to their git changelog:
http://repo.or.cz/w/MacVim.git?a=tags
and their Google Code updates list:
http://code.google.com/p/macvim/updates/list
MacVim has seen a huge number of changes in the 2+ years that TextMate has been under development: not least Leopard support, Vim 7.2 integration, and a ton of interface and speed improvements. They're on Snapshot 45 right now...
http://repo.or.cz/w/MacVim.git?a=tags
and their Google Code updates list:
http://code.google.com/p/macvim/updates/list
MacVim has seen a huge number of changes in the 2+ years that TextMate has been under development: not least Leopard support, Vim 7.2 integration, and a ton of interface and speed improvements. They're on Snapshot 45 right now...
[deleted]
As someone noted on the post's comments: http://en.wikipedia.org/wiki/Second-system_effect
Anybody who considers split windows a "surface level feature" is on a different wavelength than myself.
Please please PLEASE fix search. The awk and grep bundles suck. Coda has a really great project wide search.
I've asked allan about that in IRC, and he's said it's being worked on.
Will this be part of the "TextMate Forever" release or is it being considered for a TextMate 1.6?
As someone who uses TextMate every day, I still don't really understand the TextMate hype. It's a decent editor, but I still prefer UltraEdit (from back when I was using Windows, obviously). There's just too many little things TextMate doesn't get right.
Two examples that come to mind right away is the fact that TextMate cannot handle large files (tsk, tsk... ) and the inability to edit in hex mode.
Two examples that come to mind right away is the fact that TextMate cannot handle large files (tsk, tsk... ) and the inability to edit in hex mode.
Can't wait. However, I mostly use GVim now.
I'm just hoping MacRuby will enable the Ruby world to build our own open source Textmate clone so we'll be able to ditch this abandonware piece of crap.
> I'm just hoping MacRuby will enable the Ruby world to build our own open source Textmate clone so we'll be able to ditch this abandonware piece of crap.
Thanks for reminding me why I don't want to do Ruby.
Thanks for reminding me why I don't want to do Ruby.
Why is a complete rewrite implicitly being considered a good thing? Code doesn't get stale, there's a very active community around Textmate 1, and most people are just asking for incremental features, not something totally different. If people wanted something totally different they'd surely have ditched Textmate by now.