Starting with Snow Leopard you can however use Michel Fortin’s Magic Launch ($14) to alter the behavior. It can also be configured to open the same file type with different applications based on location, content, or similar.

There are a few reasons for this, but most essential is that with 2.0 a lot of my goals were stuff I had no idea how to do, much of this is internal features, for example looking at the core editor some of my goals here were:

• Allow threaded operations in a transparent way, not having (threaded) parser, spell checker, save (to slow network mount) etc. need to know about buffer locks and similar.
• Simple index-based API for buffer that is fully unicode aware including diacritics, combining marks, and provide scoped settings and the likes in a similarly easy fashion yet at the same time also support line-based indexing without pathetic running times and effecient batch access (search/replace, save, etc.).
• Decoupled layout code based on an API which can support “complex” layouts yet allow efficient incremental updates.
• Extend scope system to allow scopes to come from file’s location in file system and attributes associated with that location plus various other sources like SCM and general file state.
• Allow general preferences to target specific files, folders, and projects.
• Allow commands to run for events such as “document saved”, allow them to run w/o a document but also allow them to be run directly on files from the file browser.
• Provide an abstraction for commands to allow toolbars/palettes, and unified key bindings — that is, introduce an abstract action like “build” that ⌘B might call in certain contexts, but have ⌘B be “bold” in a prose context.

It is only a subset but it should show that it is about data structures, algorithms, modularity, and “abstractions” plus some unification (like make the HTML preview be a command which is re-executed based on the new event system, let smart typing be based on (nested) snippets, etc.).

To realize this I felt it was necessary to start from scratch, and it has involved a lot of experimentation, rewriting, and it is why I didn’t feel like discussing progress in the open because I had no idea about how many of my ambitions would pan out. The program itself has been in a constant state of flux with essential stuff missing because my focus has initially been on all the stuff I didn’t know how to do, as I could always do the “easy” stuff later (and doing the easy stuff first just leads to rewriting it when new insights are gained).

All in all this has been a giant puzzle with a lot of pieces that needed to fall into place. When I did the last status blog post about “90% done” it was because I felt that the last piece of the puzzle had fallen into place — of course it is never so, but all the big unanswered questions have an answer, that doesn’t mean there isn’t still a lot of stuff to do before it is alpha ready, just that the road toward alpha is no longer filled with huge unknowns.

I know a lot of you want me to give some estimate about when the first alpha is out, but if you didn’t already read the software is hard essay then please go read it now! I can’t give any estimate I am able to fulfill, which makes the entire thing pointless and will just set me up for more negative comments.

What I can say is that the code base is nearing 50 KSLOC which in my book is a lot, I didn’t think 2.0 would be more than 30 KSLOC, but in comparison 1.x is almost 40 KSLOC (but with higher redundancy than 2.0).

I feel I should stress that I am not posting these “status posts” in an attempt of painting some picture of TM 2.0 being around the corner to increase sales or avoid having people jump ship. Please make your decisions about what software to use/buy/support based on released software, not what I or someone else writes about “the future” (which none of us can predict).

Hope that gives some more insight in what has been going on for the last few years. I know I aimed to describe some of the abstractions 2.0 will introduce, but the intent was to have someone else write about this which didn’t work out, and me writing blog posts is a serious drain on my resources, and right now I really just want to finish 2.0, I also feel much better about releasing software than writing about what I think the version I hope to release in maybe half a year should probably contain if all the stars align right…

Thank you all for your patience and support during this excercise.

The way this is done is by injecting a library into the process which overload a bunch of low-level IO functions. Unfortunately this breaks on Snow Leopard, so as a quick fix we removed the library.

Since a lot of users have noticed the lack of interactive input, the instructions to get back this functionality, assuming you haven’t upgraded to Snow Leoaprd, are as follows:

1. Open Terminal.

2. Change current directory to TextMate.app, e.g.:

   cd /Applications/TextMate.app
   

3. Change into where the library used to reside:

   cd Contents/SharedSupport/Support/lib
   

4. Fetch the previous version of the library to this location:

   svn export http://svn.textmate.org/trunk/Support/lib/tm_interactive_input.dylib@11735
   

There is no need to relaunch TextMate. A quick test is to open a new document, switch to Ruby, enter: STDIN.gets and press ⌘R.

For Snow Leopard users we do plan an updated version of this library, but it is no simple fix so patience is required.

Presently two exist which have workarounds described on that page. I will release a new build shortly (that means, I planned to have it out by now ;) ) which incorporate these workarounds.

There are (or may be) issues with some of the bundle commands written in ruby (as Snow Leopard ships with ruby 1.8.7, which isn’t 100% backwards compatible). We will address these as we see them over the next weeks/months and updated versions should appear in the Subversion repository.

Before you Upgrade

If you do a clean install of Snow Leopard, make sure you have your TextMate license key handy! It can be requested from this page. If you have changed your email address since you bought the program then you can copy/paste the license key from the application by using the “Change License…” button in the dialog which appears when you select the TextMate → Registration… menu item.

Whether or not it will work out with the technical writer, time will tell. The intent was not to write blog posts myself, it might not have been clearly conveyed in the other post, but writing blog posts (or twittering) is just not my thing, hence why I am trying to pay someone else to do it.

I have however taken up writing on my old blog: SIGPIPE 13. So far it has worked out fairly well, in that I actually get content posted, and I don’t spend the better part of a day on the posts.

If you want to be assured that I am alive and still interested in computers, you may want to subscribe to that blog.

Subversion Relocation

The URL of the main Subversion repository has been changed from the forgettable untypeable http://macromates.com/svn/Bundles/ to a much nicer http://svn.textmate.org/. We made this change a while ago, but we didn’t put in a redirect before because we weren’t sure the new server could handle the load (there were some problems with the first one). We are putting in the redirect now.

Subversion doesn’t handle this change gracefully (it will just report an error and fail), so anyone using svn to keep up with bundle development needs to manually update the checkout to the new location. Here are the steps required to relocate your checkout.

In the terminal:

# assuming this is where your old chekout is
cd /Library/Application\ Support/TextMate

svn switch --relocate \
    http://macromates.com/svn/Bundles/trunk/ \

http://svn.textmate.org/trunk/

If you have “switched” subsets of the checkout, for example to test the “work in progress” (WIP) bundles, then this relocate command won’t fix the switched bundles. Run svn status in the root of your checkout, which will indicate any switched bundles with an “S” marker. For each switched bundle, find the from URL by changing directories into the bundle, and running:

svn info

This will show the URL on the second line. To make a to URL from that, just replace “macromates.com/svn/Bundles” with “svn.textmate.org”. We combine the from and to URLs when running the relocate command, for example:

cd Bundles/Subversion.tmbundle

svn switch --relocate \
    'http://macromates.com/svn/Bundles/branches/Subversion%20(Interactive%20Input).tmbundle/' \
    'http://svn.textmate.org/branches/Subversion%20(Interactive%20Input).tmbundle/'

(This was detailed in this mailing list post; instructions repeated here for convenience.)

Git for Bundle Development

For those developers who prefer distributed revision control, we’re now also mirroring the bundle repository on GitHub, at http://github.com/textmate/. This should make it much easier for you to customize your bundles and contribute back: just fork the bundle from GitHub, work on it locally, and then tell us when you have changes for us to pull back into the main repository. GitHub bundles will be kept in sync with the svn bundles, and changes to the main svn repository will be reflected at GitHub. As a bundle maintainer, you’ll be able to commit either to a fork of our GitHub bundle, or, as before, directly to svn. Anyone who isn’t a bundle maintainer will now also be able to work under version control.

For those existing authors without GitHub accounts, we used «nick»@svn.textmate.org as the commit email address. To link these changes to your account on GitHub so you’ll be properly credited (or blamed), just add that email to your account.

If you already forked a bundle obtained from svn, it would help us if you “rebase” that fork onto our GitHub mirror, as we carefully ensured proper history and author info for these mirrors. Also, our mirrors will serve as the starting point when looking for forks in the community. It is a bit of a nuisance to rebase all of these bundle forks, we realize, but it can be finished all at once, and will save pain later on. The sooner we can manage it, the better. To learn how to rebase your checkout, see Allan’s recent mailing list post.

This was initially intended as a two-way mirror (so that changes to the bundles in git would be reflected in svn as well), but the way git-svn works, we must rebase our “master” using the svn trunk, breaking the updates in one direction. So for now it is only a passive mirror. Practically, this means that when we pull changes, we must go through svn, so these changes will be given a new address (hash) and authorship info when they arrive in our master branch, requiring the fork we pulled from to do a new merge. We are looking into how to avoid this (and for this reason we are hesitant to pull changes right now: manually updating the dropped author info is tedious).

In short, TextMate development is going strong: TextMate 2 isn’t done yet, but progress is steady, it is starting to take shape, and the end is in sight. The rewrite has been a slow and careful process, but the ideas behind it are exciting. I hope to publicly describe some new abstractions in the coming weeks and months. Moreover, the community continues to churn out new bundles and features for TextMate 1.5, and I’ve been building up a backlog of posts describing them. While I am not writing to announce a release date for TextMate 2, I do hope that this post will be the first in a series showing a bit more transparency.

The requests for TextMate 1 have mostly been incremental additions such as split views, chunked undo, and editing over SFTP. But TextMate 2 is about more than new surface features. Every part has been completely rewritten to take advantage of the lessons learned from the years of version 1. Not only are the low-level data structures chosen for increased flexibility, but the abstractions on which TextMate is built—snippets, scope-based language grammars, context-dependent settings—have been rethought and are more powerful than ever. In the coming months, I’ll try to describe some of these new abstractions, but for now, know that I am excited about the new ideas involved.

So where does development stand for 2.0? It feels to me like most of the modules are getting close, say 90%. But as they say, on the horizon, mountains look small. While I use 2.0 for my own work, day-to-day, and the basic infrastructure is pretty solid, much of the front-end still needs work, and for now it’s all lacking the spit and polish of a finished app. Hopefully an alpha version will be ready before too long, but I can’t make any promises about dates.

And why haven’t I been better about keeping the world informed? It is a combination of many things really, but the main issue is that I am not good at writing for a large audience. I am more into informal conversations, for instance over mailing lists or on IRC. So while I started a lot of posts, I end up unhappy with them halfway through, and they don’t get finished or published. I am taking measures: I have enlisted a technical writer to help bring this blog back to life, and I’ll try to communicate more of TextMate’s status and direction through him.

Bigger than either of those problems though, as I mentioned, is that TextMate 2 is no minor facelift. It’s a major undertaking with a long timeline and its final form isn’t fully settled. I don’t want to hype vaporware, and I don’t want to get anyone’s hopes up before I know I can meet their expectations.

Furthermore, I haven’t wanted to throw ideas onto the internet without having a chance to implement them myself. I’m humbled that TextMate has served as inspiration for many other products, and I hope that it continues to be a model for other developers in the future, but I want to see my ideas done my way first, before I feed them to the competition.

I am trying to slowly turn this boat. With this post, I hopefully am showing that a hand is at the wheel. I know I’ve been quiet too long about my plans. I can’t make up for that, but going forward, I aim to do better.

Presently most bundles at GitHub use -tmbundle but likely because a dot was previously not allowed in a project name.

A few things still need to be translated (there is an issue tracker) but it should already be very useful for people who prefer reading Japanese over English.

And no, this does not mean that a new CJK-compliant TextMate has been released. The best approach for using CJK with TextMate is still via the plug-in.