If you are using the "Normal Releases" option in this tab this bug does not affect you.

A workaround for Transmit would be to mount the server as a hard drive and open the files from there as it would bypass the bug, this would also work in other file transfer programs that have this feature. You can get more information and alternative workarounds at the their respective posts linked above.

NSAutoreleasePool* pool = [NSAutoreleasePool new];
…
[pool drain];

To use the new autorelease blocks:

@autoreleasepool {
    …
}

Searching

We can find all the autorelease constructs using a regular expression like the following:

NSAutoreleasePool.*(?m)(.*?)\[pool \w+\];

I made the assumption here that our autorelease pool variable is always named pool. If that is not the case, one could use a back-reference.

As for the pattern: The (?m) syntax enables “multiline matching”, meaning that the “any” operator (.) matches newlines. This isn’t enabled until the second use of ., so the first .* will only match the first line (excluding its newline).

The code between declaring the pool and draining/releasing it is matched by .*? wrapped in parentheses to capture it. As we are in multiline mode, we make it a non-greedy match by using the non-greedy modifier (?), i.e. using .*? instead of just .*.

Had we not made it non-greedy, and a file contained more than one use of an autorelease pool, we would have gotten just one match from that file, which would encompass all of the pools.

Replacing

A naive replacement string would be:

@autoreleasepool {$1}

If however you enter this after having done the find, you’ll get a replacement preview and notice that this isn’t satisfying:

The problem is that the capture ($1) should be indented. Fortunately TextMate offers you its powerful format string syntax in the replacement field, which means we can perform further replacements on the capture. In particular we wish to increase the indent by one tab, which can be done using:

${1/^/\t/g}

What we do is match “begin of line” using ^ and then replacing that with a single tab (\t), specifying g as option to make it repeat (global). Looking at the preview though this isn’t entirely right either:

The problem is that the first and last lines are indented. What we really want is to only add a tab to lines which are non-empty. This can be done using the following replacement:

${1/^\t*(?=\S)/$0\t/g}

Here we match begin of line followed by zero or more tab characters and then not followed by whitespace. \S matches non-whitespace characters, where newline counts as whitespace, and wrapping it in (?=…) makes it a “look-ahead assertion” meaning that it is not part of the actual match, we just ensure the match is followed by this.

The entire replacement string now becomes:

@autoreleasepool {${1/^\t*(?=\S)/$0\t/g}}

Which gives us the desired replacement:

Addendum

The ability to process captures when doing search and replace is not limited to regular expression transformations, TextMate offers conditional insertions, case transformations, and even an asciify conversion.

You can find the full range of options in Help → TextMate Help → Format String Syntax.

TextMate 1 created the scope by parsing the document’s content using a language grammar. Though sometimes, more context information is needed than what can be provided by the document’s content, which is why TextMate 2 has extended the information stored in a scope.

Two examples of where there is a lot of choice (and thus bundles) are build systems and revision control.

For this reason, we introduced scopes for these two things. If you have the TextMate source checked out and press ⌃⇧P (Show Scope) with README.md open then you should see something like:

text.html.markdown
attr.rev-path.md.README.TextMate.Projects.duff.Users
attr.os-version.10.8.0
attr.scm.git
attr.project.ninja
attr.scm.branch.master
attr.scm.status.H

The relevant scopes are attr.scm.git and attr.project.ninja. By having a scope for the SCM system we have been able to make all the SCM bundles use ⌘Y as key equivalent (hint ⇧⌘Y is the key for showing “SCM Status” in the file browser). Likewise, by having attr.project.ninja we can scope the Ninja bundle’s Build command to ⌘B, even though this key is also used by Make, Xcode Build, and similar.

As for the latter key though, ⌘B is also bound to “Bold” in many markup languages so we have a conflict. The Build command “wins” because the attribute scopes are more specific than the content scopes which means that if we press ⌘B in our README.md then we will build the project rather than make a word bold.

If we select a word, as we would normally do before bolding it, and show the scope, we see that TextMate 2 has another nice new thing in the scope:

text.html.markdown
⋮
dyn.selection.continuous

The new dyn.selection scope allows us to override keys only when there is a selection, for example I have rebound the { key (no modifiers, but requires a selection) to wrap and indent the selection in a pair of braces, likewise } will unwrap and unindent the selection (a feature that goes well together with ⇧⌘B to first select the braces/block).

In the case of our Build command, I ended up scoping it like this:

attr.project.ninja - (text dyn.selection)

This means that for projects with a build.ninja file, we can press ⌘B to build except when in a text file and we have a selection, in that case, ⌘B means Bold.

TextMate knows about a handful of build systems and SCM systems, if yours is missing from the list, please send us a note (or pull request) and we’ll add it.

There are times when TextMate can’t provide the desired attribute scopes. For example I use CxxTest and created a bundle with snippets that only make sense in test files. If these can be scoped specifically to my tests, I can use simpler tab triggers, for example I can override main⇥ or cl⇥ for something which is more appropriate for test files, but test files are just regular C++ files, so what to do?

If you look in the .tm_properties of the TextMate source you will see we have these lines:

[ tests/*.{cc,mm} ]
scopeAttributes = 'attr.test.cxxtest'
TM_NINJA_TARGET = '${TM_FILEPATH/^.*?([^\/]*)\/tests\/.*$/$1\/test/}'

The key here is scopeAttributes. We use that to add our own scope attributes to test files, which by convention are always placed in a tests directory.

This way the CxxTest bundle can scope all its items to attr.test.cxxtest and not worry about (globally) eclipsing “standard” keys and tab triggers, when specializing them for test files.

You’ll also notice I set the TM_NINJA_TARGET environment variable for test files. The regular expression might look scary, but basically with a path like:

/Users/duff/Projects/TextMate/Frameworks/scm/tests/t_git.cc

It will set TM_NINJA_TARGET to scm/test. This means pressing ⌘B in a test file will build the framework’s test target (i.e. run the tests).

Of course this reference should be an underlined link and allow us to easily go to the online issue, yet I don’t want a 50 character long URL in the source, so how do we go about this?

Highlight

The first key to the solution is “injection grammars”. A new feature in 2.0 allows you to create a new grammar, and rather than apply it to the whole file, you tell TextMate which scope it should be applied to using a scope selector.

This means we can add small grammars for strings, comments, and similar, and we already have a few of these. Looking in the Hyperlink Helper bundle we see this grammar injected into text, string, comment (this is the version prior to my changes):

{   patterns = (
        {   match = '(?x)
                ( (https?|s?ftp|ftps|file|smb|afp|nfs|(x-)?man(-page)?|gopher|txmt)://|mailto:)
                [-:@a-zA-Z0-9_.,~%+/?=&#]+(?<![.,?:])
            ';
            name = 'markup.underline.link.hyperlink';
        },
    );
}

This means we get URLs highlighted inside strings, comments, and in text files (e.g. text.plain).

I decided on a reference syntax like <issue://157> so adding issue to the URL schemes in the above match pattern gives me highlight of these references in all comments, strings, and text files. That was easy!

Action

Next problem to solve is how to actually open them. We already have an “Open Current URL” command in the Text bundle bound to enter (⌅) and scoped to markup.underline.link so by default, pressing enter (fn return) on an issue will open it as a URL. Let’s inspect this command, you can find it by following these steps:

1. Place caret on an underlined URL
2. Choose Bundles → Select Bundle Item… (⌃⌘T)
3. Switch to key equivalent search (⌘4)
4. Press enter (⌅) to see what is bound to that key
5. Press option return (⌥↩) or the arrow button to edit that item

This reveals that the command (written as a shell script) is doing:

open "$(cat)"

The command has its input set to “selection or current scope” (presently the fallback is not visible in 2.0’s preliminary bundle editor). This means that stdin for this command will be the entire link (the “or scope” part).

We could modify this command to support the special issue scheme, but that is not elegant. Instead we make a minor but important change to the injection grammar from above. We change the name key to markup.underline.link.$2.hyperlink. What we did was add $2 which is the second capture from the regular expression, namely the URL scheme (more about syntax allowed in format strings).

This means that when we are on a URL we’ll get the URL’s scheme in the scope. So placing caret on <issue://157> (placed in a comment) and pressing ⌃⇧P (to see current scope) shows us we now have:

markup.underline.link.issue.hyperlink

What’s great about this is that we can now create a new command, still using enter as key equivalent, but using a more specific scope selector so that it only targets issue links.

This command could simply be:

open "https://github.com/textmate/textmate/issues/$(cat)"

But we can do better!

Generalization

TextMate 2 makes it easy to deal with project specific variables, I won’t repeat all of it here but instead recommend you read about folder and file type specific settings.

The gist of it is that you should place a .tm_properties file in the root of your project and in this, you can specify, amongst others, (environment) variables for the project. So for TextMate’s .tm_properties I added:

TM_ISSUE_URL = 'https://github.com/textmate/textmate/issues/%s'

Our “Open Issue Link” command can read this variable and use it to construct the final URL. Since I figured this would be useful for others than me, I added the command to the hyperlink helper bundle and its source looks like this:

#!/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby -wKU
require "#{ENV['TM_SUPPORT_PATH']}/lib/escape"

abort "TM_ISSUE_URL is unset for this project." unless ENV.has_key? 'TM_ISSUE_URL'

link = STDIN.read
if link =~ %r{issue://(.+)}
  url = ENV['TM_ISSUE_URL'] % $1
  %x{ /usr/bin/open #{e_sh url} }
else
  abort "Not an issue link: ‘#{link}’"
end

I hope it clears up some of the confusion that yesterday’s announcement may have left you with.

I’ve always wanted to allow end-users to tinker with their environment, my ability to do this is what got me excited about programming in the first place, and it is why I created the bundles concept, but there are limits to how much a bundle can do, and with the still growing user base, I think the best move forward is to open source the program.

The choice of license is GPL 3. This is partly to avoid a closed source fork and partly because the hacker in me wants all software to be free (as in speech), so in a time where our platform vendor is taking steps to limit our freedom, this is my small attempt of countering such trend.

I am also a pragmatist and realize that parts of the TextMate code base is useful for other (non-free) applications, so I may later move to a less restrictive license, as is currently the case with the bundles. For now, please get in touch with us if there are subsets of the code base you wish to use for non-free software, and we might be able to work something out.

Anything related to the code base, including contributions, can be discussed at the textmate-dev list or #textmate on freenode.net. Pull requests can be sent via GitHub but if you plan to make larger changes, it might be good to discuss them first if you want to ensure that we are interested in accepting a pull request for such change or simply want advice on how to go about it.

You can bring up any issues or questions on the mailing list or you can contact us directly by email or on Twitter.

In this article will discuss:

• The replacement of invisible characters
• Per-line soft wrap and indented soft wrap
• Dynamic font sizing
• Folding pattern upgrades

Not So Invisible

When TextMate 2 renders content, certain invisible characters are now shown in a meaningful representation, to you as the user. By way of example, if I type the following line into a shell script file and run it (with ⌃R):

printf "foo\rbar"

TextMate 2 shows me this output:

This can help you recognize as hard to detect content is making it's way into your files.

That's a Wrap

Soft wrap has multiple enhancements in TextMate 2. First, it can now be turned on and off by line. Also, you format the wrapped string, which allows for some custom indentation.

A great example of both of these are the new style settings for comments in the Source bundle. Here's a setting bound to the comment.line.number-sign scope (among others):

{   indentedSoftWrap = {
        format = '${0/\S/ /g}';
        match = '.*(##?)\s+';
    };
    softWrap = :true;
}

The softWrap = :true; kicks in soft wrapping for lines ending in this scope. That might be needed because a lot of users prefer not to wrap actual code content. Comments are prose though, so it is probably desirable to treat them differently.

The indentedSoftWrap details give a regular expression to match the line where indenting started, and a Format Strings that will be expanded in terms of that match and prepended to each line.

The effect of these settings is that a trailing comment can now be rendered as such:

It’s worth mentioning that, for the purposes of matching, a line now has a left and a right scope that we can explicitly match against via the new scope selector syntax for selecting on either side. The left scope is the line’s starting scope and the right scope (which is what’s used by default if the selector doesn’t explicitly select side) is the line’s ending scope. We will talk more about the new scope selector syntax in a future article.

Sensible Font Sizing

The first thing I absolutely have to say about font sizing is that proportional width fonts are now supported. You asked for it and Allan added it. Enough said about that.

Another nice new feature is that fonts and their sizing can be altered by scope. For example, Markdown heading now adjust their size depending on the level of the heading. This helps them standout. Here are the settings from the Themes bundle tied to the markup.heading.1 scope:

{   fontName = 'Baskerville';
    fontSize = '2.25em';
}

Now the rule bound to markup.heading.2 uses the same font at a smaller size:

{   fontName = 'Baskerville';
    fontSize = '2.1em';
}

There are rules set for the other headings as well, on down to level six.

Notice that these sizes are being set in em so they will be relative to the rest of the document content. You can also use pt (absolute) or % (relative).

Fold on the Dotted Line

The folding system has been extended with two new patterns to allow indent-based foldings. Let's look at some examples of how this works.

For example, we might want to install these folding pattern settings for C++ (scoped to source.c++):

{ foldingIndentedBlockStart  = '^\s*(public|protected|private):\s*(//.*)?$|^\s*/[*](?!.*[*]/)';
  foldingIndentedBlockIgnore = '^\s*#';
}

The first pattern (foldingIndentedBlockStart) decides what starts a foldable block. In this case it is either a visibility keyword (public/private) or /*.

The latter is to make a comment block like the following foldable:

/*
 *  t_foldings.cc
 *  TextMate 2
 *  
 *  Created by Allan Odgaard on 2011-09-30.
 *  Copyright 2011 MacroMates. All rights reserved.
 */

The second pattern (foldingIndentedBlockIgnore) represents lines to ignore. For C++ this would be preprocessor directives:

   class foldings_t
   {
   public:
      foldings_t (arguments);
#if 0
      virtual ~foldings_t ();
#endif

   private:
      /* data */
   };

This allows us to still fold from public and down to private despite the non-indented preprocessor directives.

For Markdown's folding settings (scoped to text.html.markdown), let's look at some more sneaky patterns:

{  foldingIndentedBlockStart  = '^#+\s+';
   foldingIndentedBlockIgnore = '^(?!#+\s+)';
}

We let a heading be a start marker and then we effectively ignore everything which is not a heading, causing those lines to be included in the foldable block despite not being indented. This allows you to collapse entire sections of a Markdown document down to just the headings.

These are just some of the ways TextMate 2 can now dynamically modify content as it is displayed for you. Expect to see more developments in this area in the future, as the new layout engine gives plenty of room for growth.

TextMate 2 adds some subtle refinements to this already strong collection of features.

In this article will discuss:

• Keyboard usage of Find operations
• New visual feedback provided for these operations
• How to speed up your searches
• Enhancements to the Find dialogs

The Three Shortcuts You Should Already Know

Before we get into the Find enhancements, I need to make sure you've taken the time to learn three very important Find shortcuts.

Personally, I'm pretty lax on keyboard shortcuts. I don't claim you need to know them all. Sometimes a trip into the menus is totally acceptable. In fact, there are shortcuts I recommend people don't learn for various reasons. However, there are exceptions. Some keyboard shortcuts are more important than others. Some are almost required knowledge for efficient editing. Three of those relate to Find operations:

• ⌘E (Use Selection for Find)
• ⌘G (Find Next)
• ⇧⌘G (Find Previous)

Together, these three key combos form a super fast means to navigate Find operations without even needing to stop off at a dialog first. Just select something, throw it on the Find clipboard with ⌘E, and start jumping to matches with ⌘G and/or ⇧⌘G.

The real reason to learn these keys though is that they are Mac OS X standards. This isn't just about TextMate. Any well behaved Mac program with Find should honor these same keys. Learn them once. Use them everywhere. I literally mean everywhere too, because the Find clipboard is shared between all applications.

It's ⌘G Everywhere

That brings us to the first couple of TextMate 2 tweaks.

TextMate has always had a slightly hidden feature on ⌃S. It's called Incremental Search, which is just a fancy way of saying that it starts matching as you type. The problem with the TextMate 1 version of this feature is that it used its own shortcuts for moving to the next or previous match.

TextMate 2 brings this feature inline with the rest of the OS by switching to ⌘G and ⇧⌘G for moving to the next and previous matches respectively.

Along the same lines, you can now walk through Find in Project (⇧⌘F) matches using ⌘G. Even if the next match is another file, TextMate 2 will take you there.

Now you can just remember that ⌘G means Find Next everywhere.

The Good and Bad of the Other Keyboard Shortcuts

Now that we've talked about the holy trinity of keyboard shortcuts, it's worth noting that TextMate adds one very handy Find shortcut of its own. You might want to consider devoting brain power to learning this as well:

• ⇧⌘E (Use Selection for Replace)

That pairs beautifully with ⌘E and can save you a dialog visit for operations that need a Replace as well Find.

Of course, TextMate adds a ton of other shortcuts for Find operations. One I find myself letting go of in TextMate 2 is Replace All (⌃⌘F). I used it quite a bit with TextMate 1 where I would often grab a search, press ⌘E, grab the desired replacement, use ⇧⌘E to set that, and finally Replace All (⌃⌘F). With TextMate 2's Find All (⌥⌘F) I prefer to shorten that to select, ⌘E, ⌥⌘F, and edit. See the article on Multiple Carets for a more thorough discussion of just how great Find All can be.

Earning Tips

Another tweak keyboard Find users are likely to enjoy is the addition of tooltip feedback for a few operations. If you ⌘G/⇧⌘G past the last match, a tooltip tells you that.

Also, you get a tooltip with match counts during Find All or Replace All operations. That's handy since they can involve more matches than you can see on the screen.

Finally, you will see little stars marking matches in the gutter as you are working through a Find in Project searches. This can help you see where your caret will go next and/or how many matches remain.

These are simple but appreciated enhancements.

The Need for Speed

TextMate has always had a Find in Project (⇧⌘F) feature and it's terrific to be able to scan a huge set of files or use a Regular Expression to do some clever mass editing. I'll be honest though and say that this feature took some heat during the TextMate 1 era for being on the slow side. A lot of users resorted to using tools like grep or ack to achieve similar results faster.

It you have turned your back on the feature in the past, give it another shot after upgrading to TextMate 2.

First, it's just plain faster now. That's a great start all by itself. If you really need faster searching though, it's often attainable using Find in Project's new In and matching fields to restrict a Find to certain folders and/or to a "glob" of matching files respectively. For example, *.{html,css} is a great glob for renaming a CSS class inside of your HTML and CSS files.

Remember Your History

Ever been in that situation where you thought, "I had that regex just a moment ago!". You've always been able to get those old searches back in TextMate by opening the Find dialog and using the history pop-up there.

Keeping with our skip-the-dialog theme though, TextMate 2 now allows you to use old searches straight from the keyboard. Just invoke Find History (⌃⌥⌘F), arrow down to the desired search string, and press ↩ to restart that search.

This can be pretty handy if you are alternating between a small number of Find operations.

Better Dialogs

While I've been pretty hard on the Find dialogs in this article, there are good reasons to access them at times. When you do, you'll be treated to some new features there as well.

First, the unification of the Find and Find in Project dialogs means that you can get all of the matches from a single document presented in a list (as Find in Project has always done). To see this list, use the Find All button (note that this is different from the Find All menu command).

There are also the new Full Words and Ignore Whitespace checkboxes. Full Words hasn't been implemented yet, but Ignore Whitespace allows the amount of whitespace used to separate content to differ between the search string and matched content. A typical use case for this would be if you have multiple lines of code that you want to find. For example, say that I have five lines of code that I am almost certain is copied from elsewhere and I want to refactor it into a shared function. A problem with finding the other use of that code is that it might be indented differently. Use Ignoring Whitespace though and TextMate 2 will still find it.

In the enhanced Find in Project dialog of TextMate 2, you may also enjoy knowing that ⌘1, ⌘2, … ⌘N will open that number of file with matches in it. You can see which number is attached to which file by clicking of the result list header, for a pop-up. You can also use the collapse all arrow to the left of this header to make it easy to count the files, as well as see the number of matches each contains. This can save you a trip to the mouse when you know just what you are hunting for.

It's probably obvious that the result list also allows you to control what does and doesn't get updated, via the checkbox next to each match. There are some hidden features here worth noting. First, ⌥-clicking a checkbox will toggle all of the checks for that file. You can also copy content from the result list, complete with a file and line reference. Just click on the desired entry and trigger Edit → Copy (⌘C).

Replacements are also smarter in TextMate 2. Remember that they are Format Strings, with all of the new abilities that entails. The match list will also reflect changes as you are editing a replacement string in TextMate 2. It's nice to be able to preview the changes you are about to make, before actually making them. This is especially helpful when you are using clever Format String replacements.

None of these changes are major new features, but together they really round out and add to the robustness of TextMate 2's Find and Replace operations.