I don't want to pick on Allan Odgaard, but I think the way he's handled the TM2 project is pretty bad.
Allen is a great guy and I love TM. However, here are some facts. TM2 has taken SIX YEARS. It was "90% done" 2009.
This is a living, breathing case study in why quick customer-driven releases are better than "big upfront plans" and "giant system rewrites." Anyone who has developed a major application knows what I'm talking about. These "big rewrites" almost always take much longer than expected, as has clearly happened here.
I have learned to listen to what your customers want, and just build it. Develop it in a few weeks, release it, and then ask again what your customers want. Some people call it "customer-driven development" and I think that's a good way of phrasing it.
Agreed. You have all these great ideas on how to do things better, but along the way you inevitably forget all the work it took just to ship version 1 (let alone v2 with all this improvements both feature and design wise).
That, and a reflection of the ecosystem as it was when TM2 first started development; it's a lot easier to countenance a full rewrite when you're by far the dominant player in your particular market.
Oh, not at all — but it does make the potential hubris of a rewrite (slightly) more understandable. When you have no time for a rewrite because competition is fierce, the question never really comes up; it's not necessarily the conscious avoidance of "second system effect" that it might seem.
Well, I think the GP is just saying that it's all the more tempting in that circumstance. If it looks like nobody's breathing down your neck, you might be more willing to risk a rewrite. And we love writing code so much that I think we've all heard the siren song of starting afresh.
I don't think one person would make a case study. Whatever his reason is, it would be a very specific personal reason. A case study of this will be just be like profiling a patient in a lab.
Even HN isn't immune to the problems of a karma system, whereby long detailed comments get tl;dr, and karma is as much affected by visibility as quality. A quick throwaway reply to something that ends up at the top of a post on the front page can easily gain as much karma as a long detailed reply at a later date.
I'm betting it was from Mercurial and he didn't bother to roll over the history.
From the readme:
>sudo port install ninja ragel boost multimarkdown mercurial
Yes it says later that it's only for a the SCM library tests, but it is ported to Github. Why not test the SCM library with git if you were using that? Seems more likely that he used Hg and was testing with it as well.
If I were to release any of our internal code to be open source, I would do the same. Nobody really needs to know I get lazy on EVERY Friday afternoon and check everything in as WIP.
It looks to me as though the source is freely downloadable from github if you want to compile it yourself, but the Mac installer version is being sold at its usual price.
Since you can certainly sell a GPL'ed app, is this "well-planned open sourcing" going to continue to sell the installer version, start giving it away, or discontinue it? I don't see any mention of this issue on either site, but maybe I just missed it.
There is no "installer version" of TextMate. It's just an ordinary application bundle. See for yourself — here's the 2.0 alpha posted on the Macromates blog; it will auto-update to the latest alpha:
I don't understand the negativity being shown towards TextMate in this thread. This thread is about an extremely popular editor going open source, something people have been asking for for a long time and something we should all be THRILLED about, regardless of whether we use it.
Can we save the editor wars for another thread and maybe, just maybe, actually talk about the code?
I'm personally super excited. Ever since reading this[1] blog post I've wanted to cobble together an editor with some level of libclang integration, but the amount of wheel reinvention involved kept it an idle idea. As a TM user already, having the codebase available is way more than I could've asked for.
Like you said, I don't think it has to do with the open-sourcing per se. The open sourcing is good news.
I'm not a TextMate user, but from what I've seen, this is confirmation that the TextMate author isn't going to release TM2 even though he advertised it as an incentive to buy TM1 several years ago, and has subsequently continued to promise.
I've been using Textmate 2 for the past week or so and I still prefer 1 + missing drawer. For me, the only thing Textmate 1 is missing are split views (something 2 is missing as well).
I wonder if there is still enough interest in the app where people will contribute all of the community's desired changes -- I hope there is.
Am I one of the only Textmate users who feel that Sublime isn't the right "upgrade"? I much prefer Chocolat or Vico as they feel more like native OS X applications.
+1 for using 1 and missing drawer. Never upgraded to 2 because of the bad press, and because 1.5 is good enough. It chokes on large files - and long lines, so I use vi instead for these.
I really like a few features:
* View your whole project from the root directory:
mate .
* Open a bunch of files in arbitrary locations at once:
find . -name 'something.' | xargs mate
* Write a script and run it using command-R
* Banging out html using tab complete
* Compared to any IDE it is ridiculously fast.
* I wrote a bundle (for Oracle Databases) that I used for awhile.
Kind of cool stuff.... might be available in other editors but I found 'em for the first time in TM 1.5.
ST2 is native enough for me and cross-platform should be on the list of every programmer's requirements for a text editor.
I use Vim on OS X right now and I like it but used ST2 just yesterday (odd timing). I agree with others that it is basically the TM2 we were waiting for.
> ST2 is native enough for me and cross-platform should be on the list of every programmer's requirements for a text editor.
I used to feel this way. I worked really hard to make all my configs and editors act the same across OS X and a few unix platforms. Then one day I woke up and decided I just wanted to work with the best editor on the best platform. (Both personal, subjective opinions, of course.) And that choice has worked out great for me.
When I was first looking at Sublime Text and I saw it as a disadvantage when I noticed they had Windows version. I don't mean to come across as smug, I just mean that I fundamentally feel that OS X is a lot better than Windows. (A personal opinion.) My point is that I need to be philosophically aligned with my editor's developer. And if they have chosen to support Windows, they could have spent that time pushing the OS X app forward, which doesn't align with my position. I want the best editor possible, not the best editor on every platform.
The other way I look at it is to applaud their ambition and results with creating a great cross platform editor. I think cross platform software is incredibly important, but I would paradoxically prefer my editor was not. In other words, I'm glad that ST exists, but I don't it's for me.
> My point is that I need to be philosophically aligned with my editor's developer.
This is taking things a bit too far, I think. If you're a one platform kind of person the most important thing should be "How well does it work on (my platform)?".
You're right, that is absolutely the most important thing. But as we've seen with TM, the way the project is run is really important too. It's a totally self-centered sentiment to say I wish my editor development to be exclusive to my platform, but it would certainly result in a better app for me to use.
Luckily my preferences have nothing to do with the outcome, much like the weather.
I thought about this a little more Considering the amount of attention that specific software licenses get with regards to choosing software, I think it's not so uncommon to want to be philosophically in line with your app of hooves developer.
The fact that they have a windows version is nice, but when I say cross platform I mostly mean Mac/Linux. It's one of the main reasons I chose vim in the first place. Mac/Linux/Windows GUI/Terminal. And not to start a flame war: OS X isn't getting any better for developers. It's ok. It's just not their main focus. Lucky for everyone Linux is rad and getting better all the time. Now if only there was a cross platform Fireworks like program I could switch for good...
And while it's unlikely: I may find myself in a position where I have to use Windows. I'll be glad not to need to learn a new editor I don't want to. Or maybe I'm away from my Macbook and I want to code? We aren't all complete masters of our own destiny like DHH. I like to be prepared. :)
If you haven't heard of it, ST2 has something called "Vintage Mode" which adopts a fairly large subset of the Vi/m commands. It will completely change the command set of ST2 and gets close enough to Vi for most of my needs. Notably absent is the search/replace syntax of vim, but ST2's works well enough I suppose.
Vintage mode is admittedly getting more complete every day, but as a regular Vim user the absences that exist are often a jolting distraction — attempting to use some command that doesn't exist jerks you out of your flow and it feels so inefficient to then have to remember the Sublime way of doing things.
I find it more annoying than the lack of, say, Cmd + T in MacVim, so I've found myself spending more and more time using that — even after a concerted effort to use SublimeText for a while.
This is the biggest problem with learning vim. I was an Emacs user for ages, and I could use other text editors fine. The "Emacs mode" in them usually just meant readline hotkeys: C-p and C-n for previous/next line, C-a and C-e for beginning and end of line, and C-k for delete line. These are the only real movement commands I used in Emacs, and they work in almost anything. Even nano has most of these.
But now my hands are wrecked. My fingers have minds of their own. My muscles have learned a subset of vim that does not seem to be a subset of any vim plugin maintainer's usage. I'll be in Vimperator or Eclipse vi-mode or Vintage and I'll hit cf" and nothing will happen, and I'll realize I'm completely lost. I lose my chain of thought and it takes me a non-negligible amount of time to realize that I'm going to have to hold down shift and use the arrow keys like some sort of Notepad user. I become irrationally angry and wish horrible torture upon the poor soul who wrote the (altogether pretty good) vim plugin I'm using, because who are they to not include EVERY SINGLE VERB AND NOUN that my fingers have painstakingly learned over the past few years. I slam my keyboard against the table, throw the mouse through the monitor, then roundhouse-kick the tower off the desk before I set fire to my desk every time a vim plugin is incomplete.
Vim has reduced me to a pathetic teary wreck every time I have to use a text editor that isn't vim.
Just in case you missed it, another replier mentioned an additional package, VintageEx. I just gave it a try and all of a sudden all the things I was still missing from vim are in ST2!
I recommend giving that a shot, but I do completely understand your reluctance. You're right, the absences are jarring!
I turned on Vintage mode within the first hour. Pretty nice! Funny how the single thing that turns so many off of vim initially becomes the thing you can't live without when checking out other editors.
> cross-platform should be on the list of every programmer's requirements for a text editor
As a member of the set of "every programmer", I have to disagree with this. I develop on the same machine every day. I don't care if my editor is cross-platform. I just want a good editor. It being performant and feeling "nice" for my purposes is way more important to me than being able to use it on machines where I won't ever use it.
Why should a cross-platform editor be important? Any job I do these days allows me to work in my preferred system. The code is just ASCII and it can be shared easily.
I feel ST2 is healthily past "good enough" as a Mac application. For examples of punting on that responsibility completely, look at JetBrains stuff or MonoDevelop.
I really want to like ST2, because it seems to have the fastest text engine of the current crop of editors; but as a Mac application, it's just barely better than Emacs.
1) The GUI is incomplete: look at the preferences, for instance. To change a setting, you have to open the defaults settings file, find the setting you want, copy it into a different file (user settings), and change it there. Actually, I take it back: it's worse than Emacs in this regard.
2) What GUI is there often works strangely. For example, if you open a folder you get both a sidebar and a tab bar. You can put files in the tab bar by double-clicking them, or you can browse the directory in the sidebar. But if you select a file in the sidebar which is not open in a tab, you end up with a tab bar with no selected tabs, which is quite jarring, since tab bars in all other applications always have one active tab. If you only have one tab visible, it looks like it's active even if in fact you have selected some other file in the sidebar (the fact that active and inactive tabs look very similar in the default theme does not help).
3) The default theme gives you a window that is a strange mix of light gray and dark gray, with no apparent logic. It looks like parts of two different applications got mashed together. I have yet to find a theme that looks satisfying.
The fact that settings are in a text file that I can easily sync is a GOOD thing. I don't have to rely on some godawful third party service to sync settings, I can just export them to Dropbox or throw them on a Git repo. This is one of the many things people love about Vim too, that you can set up your editor in a minute instead of trawling through GUI menus.
While flat files are a good thing, that doesn't preclude having a good interface in your app that lets you edit them. Furthermore, that is not an unfair expectation for an app that wants to be considered a good Mac citizen.
The last bit is in response to the parent post by frou_dh:
I feel ST2 is healthily past "good enough" as a Mac application.
The difficulty here is to ensure said interface doesn't make trivial changes to the flat files. Emacs has this down. As a counterexample, Visual Studio 2010 stores its settings in an XML file that, after pretty-printing, is quite human-readable. But, formatting aside, VS tends to reorder elements in this file even when you don't change anything, making sensible source control unnecessarily difficult. The somewhat manual workaround is to store important settings in a well-formatted settings file and use this as what VS calls "team" settings, because the IDE doesn't write or rewrite team settings files; this is also a nice solution because you probably don't want to sync things like window sizes and positions between a desktop with a 27" monitor and an 11" MacBook Air, and team settings only override local settings when they're defined.
I 100% agree with this. I was able to easily sync my settings between Linux, Windows and OS X for ST2, and easily find options because they are all in ONE file (Ctrl+F -what I need-), esp. considering they are very well documented. Still not as good as Netbeans for PHP/HTML (especially since it's not free), but a good settings system.
I have no issues with the settings. They are well documented and can easily be transferred from computer to computer. This is an editor targeted at developers, and as such I think we are capable of editing a config file.
I wonder if there is still enough interest in the app where people will contribute all of the community's desired changes -- I hope there is.
I don't get what you mean by "if there is still enough interest". If you wanted a particular feature or change, couldn't you just fork Textmate and then implement it? That's the advantage of it going open-source. We are not at the mercy of some developers who don't think our requests are worthwhile. If I want something on top of my open-source editor of choice, I can just "get up to speed" [1] with the source and go ahead and implement what I want.
I do think we rely a little too much on other people to do things that we want for ourselves. If you really want a feature and no one else offers to do it, then you will have to pony up and do the legwork yourself. And that's a good thing.
[1] Getting acquainted with the source code doesn't have to be that hard, either. It is a bit of a problem in less-organized projects, but still better than a closed-source base. As a developer, I think this is something more people should be used to. That is, rolling their own solutions when they don't get what they want.
>I don't get what you mean by "if there is still enough interest". If you wanted a particular feature or change, couldn't you just fork Textmate and then implement it?
No, I could not.
1) I have other things to do than building my own tools. I work creating _stuff_, not creating tools.
2) You assume I have spare time to delve into the code of a project, understand the whole structure and add a feature --which might need tons of changes all around the engine.
3) You assume I can do it. I might not even code in Obj-C/C/Cocoa. I might just be some HTML/Javascript/Python whatever developer.
>If your effort spent on tools speeds up your time-to-stuff, then the assumptions embodied in 1) are invalid.
Effort spent on tools != effort spend on adding some feature I'd like on a programmer's editor. I could just switch to something better.
Plus, you probably overestimate how more productive a tool like a programmer's editor makes you.
The truth is an editor can make editing less repetitive, but it's not like an order of magnitude better. Not even 2x or 3x more productive. Thing is, there are very successful programmers using all kinds of editors, from Emacs and Vim to Eclipse (notch), to Textmate, to Notepad++. And tons of classic unix programs, including C and Unix itself, were written in ed or similar primitive editors.
I'm going to be a bit pedantic: switching to another editor is also effort spent. Learning how to use Eclipse, IntelliJ, Visual Studio, Vim, Emacs, ed, etc. etc. Some stuff is simple (text input from a keyboard), but they each have their own weird incompatible little worlds.
Sorry, I didn't mean to attack you or anything. I'm just praising the model and abilities of open-source and how much power it gives to the user.
I'm extending this idea of rolling your own code to anything/everything open-source, not just text editors. If you're playing a game, or using a webapp and there's some feature or pain point you want to add... well now writing it yourself is an option!
Don't get me wrong, I'm not saying you have to write it because you have a thousand other things to focus on or that the reward/effort ratio isn't worthwhile or whatever reason. But you can.
But you can't tell me that having the option to do so isn't so freaking awesome. Would you prefer abandonware instead? Or seeing where Textmate 2 was going (evidently, nowhere) if it wasn't open-sourced?
>I'm just praising the model and abilities of open-source and how much power it gives to the user.
Well, what I'm tried to say it that much of this is "potential" power and not actual. It takes a community or at least several interested programmers to actualise it. Else, it's just the same as if the user didn't have the option at all.
>But you can't tell me that having the option to do so isn't so freaking awesome. Would you prefer abandonware instead?
No, sure, Open Source is better than closed source abandon-ware. Only pointing it that open source can be abandon-ware too (tons of abandoned projects on SourceForge and GitHub -- and not all for lack of interested users, mainly for lack of interested programmers).
Personally, I think that everyone should have some form of programming chops. If only so people can program in the features that they want/need into the software they use.
That's why I think programmers as users (that can contribute back!) are so beneficial. Heck, they can even help the lead programmer debug by finding stack traces, culprit lines in code, working on things the author can't make time for, etc. etc.
You're right in that it's "potential" power, but I think it's just a matter of time of getting more people into the open-source and contributing mindset. I don't think enough of my coworkers or previous peers from uni respect the power of open-source. They just see open-source software as something... 'fixed'. It's either good, or not. They don't realize that they can easily change it with some determination.
On a sidenote, have you read about the "Cathedral and the Bazaar" [1], by Eric S. Raymond? I thought it was quite an eye-opener on the merits of open-source vs the closed-source alternative.
Do you know all about batista's personal life, all his responsibilities, all of his schedule? While it is possible that he could do the work and choses not to, I don't think you have enough information to say that he definitely can do it and choses not to. People have to prioritize their lives, and there is only so much time to go around. I for one have a thousand things I'd like to do, but personal time limits and higher priorities prevent me from doing them. Finite resources cannot be made infinite.
I too still prefer TM1.5. TM2's UI is, quite simply, horrendous. That sidebar looks like something from the OS9 days. This combined with the changes to the menus and the change from ATSUI to CoreText rendering engine results in an app that quite simply isn't TextMate.
If I'm going to be moving away from TextMate as I know it, it's going to be to something better, not TextMate's uglier brother.
I tried ST2 for a month and ultimately decided it wasn't making me any faster or more productive than I was in TM1. When I do finally get to a place where I'm ready to leave TM1, it'll probably be for Chocolat. I've already bought my license.
I'll need to give Chocolat a look. Also, seeking not so much a replacement for Textmate as a product with a promising future. (I don't think this would be news if Textmate were going in a productive direction.)
I agree. Sublime is targeting cross-platform compatibility. To me that's diluting the virtues of all the systems it works on. It's not the best editor for Mac OS X, it's not the best editor for UNIX. It's not the best editor for Windows.
I prefer stronger opinion with an editor. I don't care if you have an awesome editor that only works on Windows as long as I have an awesome editor that works on my preferred OS.
Awesomeness is what editors should be about. I have to work with it all day long, it better be.
Have you used Sublime? What parts of it are not native enough on Windows and Mac?
The keyboard shortcuts follow whatever is expected on that platform. They have support for specifying different keyboard shortcuts for different OSs so 3rd party packages can also provide out-of-the-box settings that are native to each platform.
It does Lion-style save/resume your workspace so even if you shut down and restart, it opens all your sessions with unsaved work and scratch buffers still the same.
I'm not sure I found anything that made me feel this was a Mac app ported to Windows or vice versa.
No fucking way, you don't always control the environment you work on, and sometimes you want to switch OS without losing your tools. Sublime Text 2 gives you the freedom to do this. And Sublime is completely awesome on every platform.
I don't work in vi if I don't have to though, and I like editors that feel natural, are a pleasure, leverage the virtues of the OS I use, and interact with the shell. Textmate 1 has been able to do all that. It's just my preference, nothing more.
I'm a Textmate user who couldn't agree more about not liking with Sublime. I've got it as my main text editor for one of my Windows boxes, and I'm never happy or comfortable using it.
Don't you miss chunked undo? Incremental regex search and replace? Those were my main reasons to look for alternatives, back in the day. I have not looked back, ever.
I'm trying ST2 and Chocolat. I'm tending to like Chocolat better. It follows the UI conventions of OS X, whereas ST2 doesn't.
For example, ST2 doesn't let me select the folder inside a project. It only lets me reveal or hide its contents, and rather briskly, at that.
ST2 has no passion for the subtleties of user interface and the joy it can bring. I don't think a lot of people get it.
I also don't need ST2's thumbnail view of the document constantly showing me where I am in it taking up real-estate in the project window. That's clever, but a distraction, at best.
The way TextMate2 was going, I'd bet it's something like, it wasn't getting done, and the author was too busy or uninterested to continue, so open sourcing it probably is a way that it may actually ever get finished.
Less appearance than quality of implementation: I tried ST2 for a couple months but the random hangs got old (e.g. the file / symbol search would often hang for noticeable periods of time).
> This is very cool, but it calls into question what your plans are for future commercial development (by you and your team) of TM2. Is it a dead parrot?
I will remain active working on TextMate and I hope we can still sell some licenses even though people can now do their own build (w/o any license enforcement).
You don't think it has anything to do with Sandboxing requirements in the App Store and Mountain Lion having an option not to allow non-App Store applications? I'm seriously asking, not trying to start a flame war here.
Marco talked about the current status of TM2 on Build and Analyze a few weeks ago[1], and from what he said, it sounds like it has some structural performance problems that weren't getting addressed. In addition, he said that requests for bug fixes and features were constantly getting rejected by the developer, which to me hints at either a loss in interest in the project, or a lack of time to devote to developing it.
The original TextMate isn't on the App Store and I'd have to think the number of people who go into the Security settings and disallow running of non-App Store signed binaries is vanishingly small.
That setting only changes the ability to launch an app right after download by double clicking it. It doesn't actually prevent the program from running, you just have to take more steps to launch it the first time.
However TM is being kept out of the app store for other reasons, such as it's ability to prompt for an administrator password to allow writing to protected files.
Yeah, this is not true. There is a separate setting which controls a pop-up confirming whether or not you want to run an app that you downloaded, the first time you attempt to run it. The setting referred to here actually BLOCKS the running of new non-app-store (or, by default, non-signed) applications.
Apparently, you can alt-click and select open, but my gut tells me that this was an oversight and will not last long. This feature was touted as a potential way to protect children, and if overriding it doesn't even require entering a password it fails at that pretty badly.
Now you can run the application no matter what the Gatekeeper setting is set to. No need to be paranoid. Gatekeeper isn't meant to lock down the Mac against yourself. It is a security feature only.
TextMate 2 could still be distributed outside the Mac App Store, as a signed binary (with a certificate issued by Apple), and regular users wouldn’t need to change the default settings to run it.
You only need to change settings (or right-click and hit Open) if you are running unsigned binaries.
It might make sense if you were setting the computer up for a non-technical user that might install trojans. It also might be the default in the future.
OK, so I've been looking through the code and from what I see I suspect a big reason for the rewrite was to move huge chunks into platform-independent C++ for an ultimate Win32/Linux/Mac trifecta release (maybe for TM3). If so, this would explain why things got so bogged down.
The actual layout/folding code, for example, is in C++. When it needs to draw it calls Core Graphics C functions. A lot of the other things like commands are similarly abstracted. But the thing is, if you look in Frameworks/layout/src/layout.cc for example (the code that actually lays out the text), it looks like nice platform-independent C++ code. Ah, you think, this will be easy! Until you get to, say, CGRect layout_t::rect_for (row_tree_t::iterator rowIter). The return type is CGRect and it's calling CGRectMake. These are Mac-specific Core Graphics calls. The drawing code is similarly Mac-specific.
So the first thing you'd need to do is follow the architecture and start TRULY abstracting the core functionality into these C++ classes and, when they make a call to something platform-specific, you'll need to replace it with something platform-independent.
To do this, you'll need to:
- Make or move to an abstracted Graphics Context library. You could use something like Cairo or roll your own (which is what WebKit does).
- Further abstract the application structure away from the actual classes. So, for example, you would have platform neutral code to talk about the UI logically but then have each "MyWindow" C/C++ class hold a "PlatformWindowHandle" which, on Linux might be a GTKWindow pointer, on Win32 might be a Window HANDLE or COM object reference to a .NET Window, and on Mac be a pointer to an NSWindow. You'd obviously need similar platform-neutral library infrastructure to call into each of these with a similar API and translate to the platform actually running at the bottom. You could write this yourself, or you could maybe just use wxWidgets or some other library that's had a decade-long head start. You lose some control that way, though.
- Repeat with all other areas of the app that are still Mac-specific.
My opinion is this would be a good starting point for such a thing, and if you really wanted to make it happen you could. But you're NOT going to just go in there and replace NSWindows with GTKWindows and NSButtons with GTKButtons and call it a day. It will be MUCH more work than that.
I think one of the appeals of TM1 was that it WAS a native Mac app and felt like one. Qt apps never 'feel' completely native, so if you went down that path you'd end up with an awkward, substandard, non-native text editor and might as well be using Sublime Text.
as ugly as it may look, it seems like targeting something like GNUStep may help out with the portability issues. then you really only need to worry about the Mac-specific APIs.
Erm, Objective-C probably isn't the problem, even NeXt used gcc for that (not sure how much of the current feature bloat isn't in copyrighted libraries).
But GNUStep isn't exactly up to par with Cocoa, never mind not exactly the default desktop environment. Porting the whole editor from Obj-C++/Cocoa to C++/KDE or C/Gtk would be a pretty huge task, where you'd better off starting from scratch anyway (as with a lot of GUI apps, it's mostly about the ideas, not the implementation).
Don't quote me on this but I don't think the later versions of Obj-C run on gcc, but llvm/clang. Whilst thats available outside the Mac realm it depends on whether it's specifically modified.
But yeah, you're right the Cocoa aspects are the bigger overhead, I should have been more clear.
Cocotron[1] attempts to be up to part with Cocoa though. I'm not sure if it would cover everything needed by TM, but it would be a pretty decent start.
Considering that the only reason GNUStep isn't considered a totally failed project is the existence of Hurd, I wouldn't bet my money on creating a reasonably up-to-date cross-platform Cocoa/OpenStep clone. Try to see if the base Objective-C++ is working alright and create a GUI-independent layer, at least that way you'll get your native look-and-feel for free. But looking at the code, I think that'll excisce a lot of the core TM tech, so whether it's worth the conversion effort instead of just starting brand new is a pretty good question.
Browsing through the code, Objective-C seems to be used for the UI, but the guts of the code (the Frameworks directory) is in C++.
I have mixed feelings about TextMate going open source. If QuickSilver is any indication, it will now definitely take forever for a new release. Dang! and I seriously don't like ST2.
I know and it's great, but from Alcor released QS as open source until it was picked up and new proper releases started to emerge, it took 2-3 years? So waiting 6 + 2 years (in the best case) for TM2 is too long even for me. RIP TM2.
Define "new release," because Quicksilver's core app and plugins are being updated rather frequently now for bugfixes. As far as adding new functionality, that might be right but what else do you need core QS to do? It would be nice to have an additional plugin or two but as far as core QS, I can't think of anything it doesn't do that I would like it to.
If TM isn't updated much, then it's because of the same reason that QS is not updated much anymore, because most people moved on to something else and are no longer interested in it.
It's better than nothing. The lack of activity means the author isn't very interested in continuing the project. But you can find another lead developer to run the project, at least. That's the merit of open-source.
I am not sure how to read the statement by Allan Odgaard. It does not include any hint on the future of Textmate: Has Textmate become open source abandonware or does Allan Odgaard intend to lead the future development of Textmate as an open source?
The latter would of course be great, the former rather sad from a user perspective since most former closed source apps do not survive for long after a switch to open source.
It does, actually. He mentions asking about pull requests and such, so it's clear he (or they, as it's all pluralized) intend(s) on maintaining the repository.
I stopped using TM1 for one reason: undo (which is one. character. at. a. time.) TM had a lot of fans, but no-one liked its undo (some didn't dislike it that much).
I've been using it since the first alpha release back in December or whenever it was released and I can say that alpha absolutely fixes the one character at a time undo (and has since the first release).
This is going to be a mess initially. So far there has been a pull request changing the license, and issues such as "Improve syntax highlighting performance. It sucks much compared to Chocolat or Textmate 1 currently."
TextMate 2 tarball for your downloading convenience: https://dl.dropbox.com/u/10047/TextMate2.tbz Binary uses latest source. [I compiled and tested, works on Lion at very least]
I'm confused as to how he could ever sell Textmate2 if he's linking against ragel, a GPL library. Well of course he could sell it but he'd have to release the source.
ragel isn't a library. ragel takes input and turns it into a state machine. The output from ragel isn't under any specific license other than your own, see the section on license on the homepage (copied below)
http://www.complang.org/ragel/
> Note: parts of Ragel output are copied from Ragel source covered by the GNU
> GPL. As a special exception to the GPL, you may use the parts of Ragel output
> copied from Ragel source without restriction. The remainder of Ragel output
> is derived from the input and inherits the copyright status of the input
> file. Use of Ragel makes no requirements about the license of generated code.
ragel is actually extremely cool and I've used it extensively in non-open source code for various things. I haven't even scratched the surface yet with how powerful it can be and I definitely want to spend more time with it.
I think this was something a lot of people had seen coming. Really at this point it was only Hardcore Textmate users left. Most people in our office use either Sublime Text 2, BBEdit, Emacs or Vim. Sublime has made the change from Textmate really easy.
It's good to see that they are sharing their hard work with the community but it's sad to see a legendary text editor basically die!
Considering the age of the project it probably wasn't being managed in git to begin with. I've seen some estimates that Allan started development around 2006. Git only came out in 2005 and took a few years to gain traction.
I've never used the git transfer plugins but I've had some past headaches moving to different source control systems. I usually just start a fresh repository with the latest snapshot and keep the old system available if anyone has to really go back that far (in my experience after a few weeks no one really ever has had to do this).
The product I'm working on most of the time started 2004 as a CVS repository, then was converted to svn where it spent a lot of time in and hen in 2009 it was converted to git where it lives ever since.
I've had no issues during either conversion (aside of mistyping an author name, but filter-branch helped). All branches were successfully transferred.
Weird, what kinds of headaches? So long as the HEAD of the converted repo has the same code as the snapshot, what's the difference? Does the conversion break the new repository somehow? (The only way I can think of that's not a bug is slowdown.)
That's great :) I mostly use vim on the command line, but Textmate is great for dealing with Rails applications. I know, there is the nerdtree plugin for [Mac]vim, but the Textmate folder view is much better imho. Also, it's a nice tool for beginners, because you have zero configuration, but a really powerful editor.
I think this is the right move. In my opinion, TextMate is not that great to ST2 or some other editors. Hopefully, it being open-source can get it closer to being on par. All I can say is thank god I never bought previous versions of TextMate and went with great alternatives.
I can't imagine this was because Textmate isn't selling well enough.
I could be wrong but I always looked at Textmate as an example of an app that must be making a killing.
I haven't used TM2 since it was first released however if its like TM1 'Replace' only appears on the single file find (cmd+f) and is not available on the find in project (shift+cmd+f) dialog.
In the Find in Project (in TM1, I've not used 2), just cmd-click to select the found instances you want to replace, and the Replace All button because Replace Selected
Whilst the site is down at the minute I can only offer conjecture. Basically, people waited so long for TextMate 2 to arrive, when the betas finally did land it was totally underwhelming. Sublime Text 2 had already started to replace TextMate for most Mac developers and finding out that the wait for TextMate 2 probably wasn't worth it probably just made people move over. I know a year ago everyone in my office used TextMate and now none do for pretty much these reasons.
You can't currently pay for version 2 - it's in alpha, and isn't close to being released. And, as mentioned above, owners of version 1 were automatically supposed to get a license for Textmate2.
I don't know how long ago you paid for it, but I paid £35 for my license 3 years and 1 day ago (August 8th, 2009)
3 years of use from a product, plus we now have the almost-guaranteed support and speedier development because of it's Open Source nature. I think it was worth the money.
If you paid for it last week, I can understand frustration.
Not wrong may be but definitely not logical. Its like saying "I am miffed because I paid $500 for 32 MB of RAM 10 years ago while I can now pay $100 for 2 GB of RAM". Different times, different technology.
Exactly. I was just a hypothetical price but you proved my point even further. Side note, I have actually not bought RAM for like ever. Its been ages :). I guess did not need to.
If you program for your day job you're using your editor something like 2,000 hours a year. I paid for TextMate something like 5 years ago... given that I used it for approaching 10,000 hours since then...
A text editor and a computer have such an amazing return on investment it makes anything else pale in comparison. Even if you're paid $50,000 per year, your $50 investment into TextMate made you $250,000... or paid for itself 500 time over. (Edit: Sorry, I mean 5,000 times over.)
5,000 times, and that's only if you hold TextMate responsible for the entire income. A more informative valuation of TextMate would be to compare your productivity with it versus a free alternative such as Emacs, vim or Eclipse. It may well be worth much more than $50 to you, and therefore a great deal, but probably nothing like a 5,000X ROI.
You mean 5000 times over? This assumes, however, that if you didn't have TextMate, you wouldn't earn anything at all (and would still work full time). If you paid for it, only used it at work, and it made no contribution to your earnings, it wouldn't pay for itself at all, except in terms of your own happiness.
I paid for Textmate too, for Textmate I. That being said, I'm sad that the development of Textmate has come to an end. Switching to another editor sooner or later won't be easy.
I recently also switched to Sublime Text 2, and while there are still a couple of hiccups, overall it has been an awesome editor to use. It's global search is blindingly fast, saving me tons of time while developing. Definitely recommend switching when you have a few hours of free time.
Thanks, SublimeText is certainly a possible candidate. For the moment, I can still use Textmate 1. That gives me some time to test other editors including SublimeText.
I bought in Jan 5, 2006. I never preferred it as a text editor, but Odgaard mentioned on the MacBS list that the licenses were sequential, so I wanted to see how much a trendy one-man Mac text editor sold. My license was #4814, which means he probably grossed about $250k over those first two years.
A year later, I bought it again... that time my license number was #37475. (Though I think at that point it had been in various promotions and bundles, so who knows how much $ it translates to.)
I can grab 5 to 10 more keyboards just like the one I am using right now for free. No history of use is going to bump the value of this keyboard. It is a piece of infinitely replaceable crap that bends like a paperback book.
Until you get RSI from your crappy keyboard. Which is why people will pay $100+ for a keyboard.
I've bought 3 Microsoft Natural 4000s (about a $60 keyboard) over the past 3 years simply because I was away from my office for an extended period of time and my wrists started hurting.
No see, you are including more sensible factors in your calculation of utility. The issue is just justifying price with "how much have you used it for work related activities", which is silly for just about everything except maybe soothing buyers remorse.
I have an old Model M at home that I value at a hell of a lot more than $10; I am not here to argue the merits of expensive keyboards. My point though is that the cheap keyboards I have around that have gotten a lot of use are not worth more because I have gotten a lot of use from them. No matter how much work I have gotten paid for while working on a $10 keyboard, it is still a $10 keyboard.
I downvoted your original response, but your point became better articulated as you went.
The value is in replaceability. It comes down to the question, "if I take this away from you, what will you do then?".
Textmate was valuable because it was a piece of software that its users could not easily replace to their satisfaction.
If I take your $10 keyboard away, your next move would be to pick up some other $10 keyboard. Hence why the value is $10.
Some pieces of software are valuable even if you barely ever use them. It may be something you use once a year to complete a project, but if it's not easily swapped out for some other replacement, and completing that project is something of high value to you, then that piece of software is valuable - much more so than the small amount of time you spend using it would indicate.
I will readily agree that Textmate has value. Great value to some users.
My only issue is with what I saw as a suggestion that if you are dissatisfied with a purchase then you can offset that by using that purchase a lot.
Presumably owenjones thinks he paid too much for textmate/textmate2, and presumably was not planning on using textmate/textmate2 for less than two years when he thought it was a good deal. Pointing out that he should be satisfied because he used his purchase for two years so far seems very silly to me.
If you use something for longer than its expected lifespan, then I can see it. If you buy a car expecting it to last 100k miles but it lasts 200k miles instead, then yes you should feel satisfied with your purchase even if you feel you were being ripped off at the time by the dealer. -- Now, if you were planning on 100k miles, and got 100k miles, then simply getting the usage you were planning on getting at purchase time really shouldn't make you feel better about being overcharged.
So you think if I use a shitty keyboard for a long time, that would justify paying more money for it in the first place? Sounds almost like a sunken cost fallacy to me. You should not feel obligated to continue using something because you regret paying so much for it. Had I paid too much for my keyboard, I would not attempt to comfort myself by using it more. Similarly, I would not find comfort in looking back at how much I used it.
The intrinsic values that the keyboard itself has should set its worth, not the value you extracted from it in the past. It is a keyboard, not an heirloom.
Surely it's worth no less than its replacement cost, which is the price of the replacement keyboard plus the work lost due to the time spent getting it and plugging it in.
This is only going to be <$10 in general if you have a pile of spares right to hand, with unit cost <($10 - epsilon).
Not having a spare, it'd cost me a lot more than that to replace my keyboard. Gulp. Better get one...
If we are completely honest, Textmate was always a sub-par editor.
No Vim or Emacs style brilliantness, no BBEdit style tons of features and mature engine, no IntelliJ like, er, intelligence, no ST2 comprehensiveness, etc etc.
Plus, the Textmate 1.x text engine was probably a mess too -- I remember the very first versions being laggy (and that's coming from someone who doesn't find even Eclipse laggy). That he couldn't easily fix the one-character-undo is another pointer to that (and, for all I've seen, the 2.x engine is not that better).
It's main saving grace was the many extensions it had, and looking half-decent and native on OS X. Basically, it caught on because it appeared on the right time, and appealed to OS X users like web programmers etc, that wasn't old-time unix buffs, and wanted something native looking without forking for BBEdit (which itself was/is Carbon based and with a custom text display widget).
I don't think Textmate deserved all that success --it should have happened to a better editor.
I disagree with your assertion. TM 1.x was an amazing piece of software and way better than numerous text editors out there at the time.
Usability wise it was impressive, keyboard shortcuts made sense, creating your own snippets and extensions was a breeze, block mode was simpler than on any other text editor out there and there was support for most programming languages out of the box.
Consider for a moment that Gedit and Notepad++ are used professionally even today by many devs.
While I'm a big fan of Vim today and wouldn't go back I think TM 1 was a step up for me as it was for numerous other developers at the time. I went from using Gedit to Textmate and I was blown away by the feature set.
I think you're either forgetting, or never directly experienced, how much nicer TextMate was (and is) for dealing with files that mix different languages. PHP/HTML, Javascript/HTML, CSS/HTML, etc. TextMate automatically detects the language shifts and modifies syntax highlighting and snippet shortcuts. This was huge. No more jumping from PHP mode to HTML mode to JavaScript mode: it just worked.
Yah, same here. I still have the muscle memory for emacs and I've gone back a few times and tried it, but honestly, the configuration was such a pain in the ass. I have .emacs files from long ago, but I tried a few months back bringing it up to date along the lines of TM1 and after about 15 mins, I just said forget it.
TM1 out of the box had all my web dev needs already there. Plus, tabs worked great. The only things I've replaced on it over the past few years were search in project (via grep in project) and the file drawer on the left (forget what that plugin was called). Speaking of plugins / bundles - those were super easy to install. For what I needed, they pretty much just always worked.
For the OP who said that Textmate didn't deserve its success I say, whatever. Everyone that I worked with over the past 5+ years doing web dev used TM. And NO ONE complained that it got in their way of getting their work done. So, cool, that's your opinion, but I think TM deserved all the success it got - it's helped me make a good amount of money over the past few years and I still use it today.
The fact that TM2 is now on Github, that's great. Will anything come of it? Dunno, but I guess I can't blame Alan for putting it on there and maybe moving on. TM1 is almost 8 years old and that's a long time to be beholden to something. Oh, and I never felt ripped off; it was money well spent and has lasted a long time..
More saving graces for TextMate 1 even today: It is right at home on OS X and also acknowledges the usefulness of UNIX. / It has no learning curve. / It requires zero configuration to be perfectly usable. / The shortcuts are as intuitive as it gets. / The only shortcut that I found weird was "cmd+T", and that one has been widely copied.
If you say that another editor should have been as successful, then what do you mean? That TextMate users have never heard of vim, emacs or ST2? That developers have been lazy and should have out-done TextMate (which ST2 arguably did)? I think this as clear of a deserved success as it gets - it's a programmer's editor and people decided it was the best one to program in.
I agree with you insofar that I tried it and didn't quite get the appeal personally. But I had alot of experience with VIM coming in.
The degree of success is something I allude to as being congruent with the success of Apple products in general - well designed, cohesive, but definitely not the core demographic being power users. If anything you could probably say it was many's first powerful editor... and as people people grew in their abilities lament formed from its limitations, much of which was to be addressed in TM2, but the extended wait opened the door for people to move onto other, more powerful editors, and esp. set the stage for Sublime - which I'm neither here nor there with and may go back to VIM. But hey, its plugins are in Python and it has a VIM-like mode with an elegant UI so it's definitely a solid step in the right direction.
I think its success was well deserved given its core demographic and esp. tie-in with the Rails community which seemed to grow with it. I'm glad it existed, I consider it a great 'gateway' editor :) And now Sublime is its spiritual successor and I consider that a pretty good thing. Some people, esp. web designers, are just not going to give up UI polish no matter what so it is what it is. And it may very well have introduced others to VIM or EMACS who wouldn't have given them a look initially, finding the old school look and complexity daunting at first blush.
What drew me to TM1 were the several innovative features for the time (mid 2000s) that were promptly copied into other editors (and sometimes improved there):
* snippets
* fuzzy file finder
* project file list
* multi-column editing
This is in addition to the non-text related good things TM did: grouping languages, snippets and scripts into a single folder, the bundle community, etc.
However, those 4 features were what moved me over to TM - I was more than willing to plunk down my $50 for these features that no other editor (at the time) had
The fact that the file list correlated to the contents of a directory was a huge deal. XCode and other editors require "projects" to be assembled. TextMate could also ignore certain paths if configured correctly, cleaning up projects considerably.
I used SubEthaEdit prior to TextMate and was quite happy, but it lacked multi-file editing and tabs.
"brilliantness"? Are you kidding? Have you worked with vimscript? Oh well, at the risk of feeding a troll...
Textmate introduced a huge number of features that now show up in other editors. Snippets, command-t, a tightly integrated community-driven extension system.
Textmate was a lightweight editor for lightweight dynamically typed languages. It was the perfect contrast to Eclipse and Java, and was instrumental in changing the status quo for web development (for the better, imho).
>"brilliantness"? Are you kidding? Have you worked with vimscript? Oh well, at the risk of feeding a troll...
No, I haven't worked with vimscript. What does it have to do with anything?
Vim/vi is a brilliant piece of editor software, with a solid concept (an editing language, the dual modes etc). And it is in continuous use for 30+ years now. Does anybody disagree with that?
Now,vimscript being crap, or even it being totally absent, would not change those facts. In fact, most of the decades of vi/m using by hundreds of thousands of programmers have been without vimscript existing at all.
Btw, please don't use the word "troll" out of context. I made an argument. Reply or ignore it, but don't use conversation killing words like "troll".
vim is great, but most of its great features are at the end of a very difficult (but necessary) learning curve. The learning curve for developing plugins is even steeper (and unnecessarily so).
In contrast, most people can pick up and use textmate instantly. They can alter the extensions easily, since everything is done in a sane script environment (python/ruby). They can also share/alter/manage their extensions more easily without causing conflicts. Pathogen/vundle are recent vim plugins that finally make this easier for vimmers.
In a sense, textmate changed the nature of what an editor was about. I think extensions are a large part of an editor's value now. ST2, vim, and others are now following textmate's approach, and I admit, they're doing a better job of it than textmate. However, you still have to give credit to the originator.
Vim had "extensions" before TextMate even existed.
I don't speak Ruby so I've never been able to alter much of anything in TextMate beside creating/customizing snippets in my 4 years of heavy usage (user ID in the lower 4 digits).
However, picking up vimscript for my small needs was relatively easy.
I'm talking about light weight editors that support light weight scripting in a number of different languages. I consider emacs to be more IDE-like. That's admittedly a weak distinction though.
emacsclient is about as lightweight as it gets, and Cocoa Emacs itself (24.1.50.1, built from the Git repository on Savannah this afternoon) starts up in less than 5 seconds on my Mac. As for "scripting in a number of different languages", that's more of an anti-feature for me. Specifically, running Emacs in a Windows, FreeBSD, Linux, Solaris, ... VM in VMware Fusion, I can symlink the init files and site-lisp directories in my guest OS home directory to the analogous items in my OS X home directory, and, given reasonably comparable fonts and Emacs versions, my Emacs configuration and most extensions work identically in the VMs.
If, on the other hand, these extensions were written in a number of scripting languages rather than Emacs Lisp, I'd need to maintain a like number of scripting language runtimes in each guest OS. Given the amount of code I write in Emacs pales in comparison to the amount of contributed third-party code I use, the fact that I have to write it in Emacs Lisp is a vanishingly small price to pay. Besides that, for lightweight scripting at least, I actually like Emacs Lisp.
I agree that emacs is losing its stigma of being/feeling bloated. Also, lisp is finding more practical applications through clojure. It seems like emacs should be on the upswing. So, charts like this (taken with a small grain of salt) are puzzling:
http://www.google.com/insights/search/#q=emacs&cmpt=q
It's main saving grace was the many extensions it had, and looking half-decent and native on OS X.
One of the key features it had in the early days, that most other OS X editors did not, was a file tree drawer that worked well. From the terminal, you could type "mate ." and you'd have an editor with a file drawer right there. No "project" BS, no modal dialogs to navigate around files.. all very handy for working on file heavy Rails projects.
Exactly. Window is folder and tabs are files, that arrangement feels completely natural, and Vim never got there with all its own buffers and windows and tabs and so on. Nothing else ever got there (on OSX) until Sublime.
Yes, the extensions are its saving graces. I'd use it for typing up a web page in HTML, but as soon as I try to type in Japanese characters, it all goes to hell.
No, seriously. Typing Japanese characters in TextMate is a worse experience than, say, typing them into a terminal window, or typing them into an aged Carbon application that was obviously not designed for Japanese input.
I've been a TextMate user since... well as long as I can remember (I was so glad to be done with all those BBEdit trials– seemed liked every time a new MacWorld magazine was out it would come with the latest and greatest... BBEdit). But, over the last year or two, this is the one problem that has caused me to revert multiple times to other editors. I was hoping TM2 would improve on this a bit but so far nothing's happened.
It won so many adopters because it was simple and pretty. The advanced features are great, but TM won because it didn't have Emacs/Vim learning curve, and it mostly just worked.
VIM learning curve.. It takes 2 hours (at least it did for me 8 years ago) to go through vimtutor, which means you can do all the basic stuff like with any editor. That's it. From that point you can stay or go how ever far you want. From using the editor "the notepad level", go nuts by building a database of key shortcuts and commands in your head.
Is 2 hours a considerably "steep learning curve" for the thing you are going to look at and interact with 8 hours/day, 40 days/week, for the rest of your engineering career?
2 hours? Once thing is reading a tutorial in that time and another is use vim without having to think to enter command mode and moving around comfortably.
I use vim daily and it's my editor of choice (so far, at least), but it needs commitment and time to get use to the modal system and to be used without feeling that is absolutely broken. After 8 years I'm sure it feels very natural (as it feels now to me), but I sure remember that it took me time to get use to it. It's not just reading a tutorial...
I must disagree with you. I have used TextMate 1 for many years. Lighter weight than Emacs for quick edits and rapid file browsing. My usual use case is working in a shell and using the mate command line alias to quickly view/edit files. BTW, I use IDEs for serious development: I don't open TextMate and stay in it for an hour, rather using it for fast little tasks. I have received huge value for a low price.
TextMate lacked polish, I think that is the fairest indictment you can make of it. It really did bring some awesome features and customizability to the table with probably the lowest difficulty-of-customization to flexibility ratio in the history of editors. It's easy to dismiss how impressive it was in 2004 because so much of it has trickled down to other editors. It really goes hand-in-hand with Rails which people are so quick to criticize today because of how much improvement it spurred in the competition.
This is pretty harsh, but you're right: it was always sub-par, with some compelling features. As a long-time BBEdit (and thus Mac) user, my impression was Textmate appealed to "switchers" who may not have been aware of better options.
I tried Textmate many times, but single-character undo was always unforgivable.
> I tried Textmate many times, but single-character undo was always unforgivable.
I've heard this complaint before. On the other hand, I can't forgive multi-character undo. I think it's just user preference.
Furthermore, I still use TM1 all day every day. When people call it sub-par or compare its features to other editors it often reminds me of the checklists comparing the first iPhone to other (crappy) phones at the time. You can check all the boxes you want, but if the product doesn't get the details right it doesn't matter. TM isn't for everyone, but it's certainly for me, and I shopped around. (I don't mean to imply all other editors are crap.)
edit: I'm a life long Mac user, 15 year emacs user. I think it has a lot of appeal to non-switchers. That said, it definitely rode the Rails wave.
Are you kidding about the undo thing? I can understand that some people might like TextMate despite its flaws, but I cannot imagine that anybody would really prefer one-character-at-a-time undo.
I've been developing for the Mac for since 2000, and TextMate is the only app I can recall seeing with that "feature".
Everyone has a right to their opinion but "No Vim or Emacs style brilliantness" followed by "I don't think Textmate deserved all that success --it should have happened to a better editor." doesn't really make sense does it?
What TextMate did do was act as a nice gateway drug to Vim and Emacs for many developers and also paved the way for other editors like SublimeText to prosper. Who would have thought that a one-man text editor startup on a single platform could actually be financially viable?
TextMate came up with the brilliant idea of "textmate bundles"- the fact that both Sublime Text as well as E-TextEditor on Windows will import/use these bundles is a pretty good sign of how good that idea was.
Regardless of whether TM deserved its success, its time has past. I took this as a reminder to finally delete the binary from my Mac. Sublime all the way, and without irritating licensing restrictions.
>I don't think Textmate deserved all that success --it should have happened to a better editor.
This doesn't make much sense. You say it appeared at the right time and was pretty and native on OS X. What better editors deserved the success it had that were available when TextMate was popular? Which editors were available on OS X that weren't giant IDEs or VIM and Emacs style editors that have a ridiculously steep learning curve?
I've never understood when people say something or someone doesn't deserve something they've earned. TextMate is successful because lots of people bought it. Who are you to judge what deserves to be successful and what doesn't, especially when history seems to disagree with you?
The early and enthusiastic support of DHH / the Rails community had a lot to do with the initial success of TextMate. Whether this was 'deserved' is too subjective to be worth debating. It happened, and TextMate took off as a result.
Community effects can never bring a poor technology to the top. They can keep a great technology from overtaking a good technology, though. But TextMate's success was not only from the community support, but also from its capabilities. Snippets were one of its cool features, for example, that helped it gain success.
Vim has snippets too. I'm sure there's an Eclipse/Visual Studio plugin that provides the same functionality. There's really nothing revolutionary in here.
Thanks for pointing this out, and I don't disagree. It's debatable whether TextMate was revolutionary or a huge leap ahead of the competition at the time. But batista claimed that "Textmate was always a sub-par editor" and implied that its success was due to hype, not its capabilities, which I find hard to accept as true.
I'm not claiming that TextMate was the best choice, just that it's unfair to call it a bad choice or sub-par. It was a very solid, decent text editor.
textmate is appealing because it always had a great default configuration. For many people getting old-school editors to play well required too much config ninjaing.
> people who don't have time to learn an esoteric system
if they had time to learn a programming language why they don't have time to learn how to speak with Vim? also I don't think that vim commands are more "esoteric" than (eg) objective-c
and actually, if you are short of time then you should learn to code faster with a faster text editor like Vim (or Emacs of you prefer..)
Two points worth mentioning. Emacs 2.4 comes with many features by default that shrink the learning curve.
And most importantly, check out Technomancy's emacs starter kit. It even comes with a package that lets Textmate users keep using their familiar keyboard shortcuts if they want.
>This doesn't make much sense. You say it appeared at the right time and was pretty and native on OS X. What better editors deserved the success it had that were available when TextMate was popular?
The fact that there wasn't another editor that fulfilled all those "needs" at the time (mainly: simple, native looking) does not mean that it deserved it's success. What I'm saying is, it got its success not because it was better than the competition but because there was no competition.
So, I just wish that something better was available at the time with the wanted features (mainly: simple to use and native looking). It would have been better for all in the long run.
>I've never understood when people say something or someone doesn't deserve something they've earned.
You can earn something for lots of reasons, not always the best of reasons. Nixon got the vote, doesn't mean he also deserved it.
>TextMate is successful because lots of people bought it. Who are you to judge what deserves to be successful and what doesn't, especially when history seems to disagree with you?
Actually history seems to agree with me. Did you miss the part when the promised 2 was worked on for 6 years, got nowhere, delivered a disappointing alpha and got dump half-heartedly (as in with GPLv3, with the intention to continue commercial development) on GitHub?
> The fact that there wasn't another editor that fulfilled all those "needs" at the time (mainly: simple, native looking) does not mean that it deserved it's success. What I'm saying is, it got its success not because it was better than the competition but because there was no competition.
What kind of doublespeak is that? If there's a race, and you're the only one who shows up, you deserve to win, period.
> Actually history seems to agree with me. Did you miss the part when the promised 2 was worked on for 6 years, got nowhere, delivered a disappointing alpha and got dump half-heartedly (as in with GPLv3, with the intention to continue commercial development) on GitHub?
I dunno. I think the part where he could afford to spend 6 years working on some pie in the sky product which never released, subsisting entirely on income from TextMate 1 which was minimally enhanced during that time, suggests that history agrees with the "TextMate was very successful" view.
Not sure why this is supposedly so much better than ST2. I've got a Go(lang) bundle installed and a theme that I prefer over my current ST2 theme, but I like the file browser, tabs and menu layout better in ST2.
I think it's a likely death sentence, although certainly not a guaranteed one.
Clearly a lot of open source projects maintain active development for years/decades. But there aren't many success stories I can think of offhand when it comes to closed source commercial software converting to open source. The only big one that immediately comes to mind is OpenOffice, and it's a pretty unusual case -- it still had an actively-maintained proprietary commercial version developed alongside the open source version for years.
If you as an individual think having your editor be open source is critical, you weren't using TextMate anyway. If you were using TextMate, you're probably willing to pay $50-60 for a "Mac-like experience" with a closed source but extensible editor. That mostly leaves diehard TextMate 1.x users and people who would try a free TextMate for beer rather than speech reasons. I'm dubious as to whether there's a sufficiently talented and motivated subset of that group to seriously further TM's development.
Lastly, I'm not sure there's room for another "industrial strength" open source text editors. It's probably not much of an exaggeration to say that there's Emacs, Vim, jEdit for the weirdos, and Things Only Their Authors Use. And in all of the big cases, those editors are cross-platform. TM isn't and won't be for years, if ever.
Not at all. If something is open-sourced at the height of its power that's an incredible development.
TextMate is dead simply because everyone's already written it off. Some people are still on TextMate 1.5 because of the strength of the product, but it's been hemorrhaging users for years, and the TM2 alpha has been underwhelming to say the least.
I mean it's really hard for someone who wasn't around at the time to grok how amazing TextMate was at its release. I first saw it in the Rails demo and was like "what is that, I've got to try it right now". For all the build-up that TM2 had, after that long a wait it needed to pack a serious punch like that to reinvigorate people. Instead it just seemed buggy and slow and not something you'd want to do serious work in.
That we're having this discussion about a text editor that hasn't seen a real release in around six years (not counting the TM2 beta) is a testament to the enthusiasm. I'm hopeful and optimistic.
Allen is a great guy and I love TM. However, here are some facts. TM2 has taken SIX YEARS. It was "90% done" 2009.
This is a living, breathing case study in why quick customer-driven releases are better than "big upfront plans" and "giant system rewrites." Anyone who has developed a major application knows what I'm talking about. These "big rewrites" almost always take much longer than expected, as has clearly happened here.
I have learned to listen to what your customers want, and just build it. Develop it in a few weeks, release it, and then ask again what your customers want. Some people call it "customer-driven development" and I think that's a good way of phrasing it.