Enter thor.

The idea behind thor initially came from my work on a textmate binary (more on that later today), which would manage installed Textmate bundles. Sure, there’s the getbundle bundle, and you can manually get bundles from subversion, but I wanted a single binary that handled all of that.

While I was building it, I decided to map the commands that people could enter to a class and its methods. I created a small file that I included with the textmate binary called class_cli, and created some syntax for mapping things, like so (note that this is not the final syntax):

class MyApp
  include CLI

  desc "list [list]“, “list some items”
  def list(list = “stuff”)
    puts list.split(/,\s*/).join(”\n”)
  end
end

MyApp.start

Assuming the binary is called app, you could then do app list "one,two,three", which would print:

one
two
three

In the case of the textmate binary, I created methods for list, install, installed, and uninstall.

This worked nicely, so I wanted to extract it out for use in other tools. I started the Hermes project on github, but while drinking with Chris Wanstrath, I was convinced that the name Thor would be more appealing. Oh, the things that alcohol can do. I was also convinced of a couple other things (again, in a slightly inebriated state):

• rake and sake needed to be replaced for scripts, not as a replacement for make
• nobody was going to use hermesthor if they need extra boilerplate like MyApp.start

Long story short, Chris convinced me to make Thor a full-fledged scripting solution. So I did.

Thor, as it exists today, has two components:

• The Thor superclass, which works exactly like CLI/Hermes, except that you inherit from it instead of including it (class MyApp < Thor).
• The Thor runner, which can run Thortasks that are in a local directory or installed from a remote location

The thor runner allows you to make files like:

# module: random

class Amazing < Thor
  desc "describe NAME", "say that someone is amazing"
  method_options :forcefully => :boolean
  def describe(name, opts)
    ret = “#{name} is amazing”
    puts opts["forcefully"] ? ret.upcase : ret
  end

  desc “hello”, “say hello”
  def hello
    puts “Hello”
  end
end

If you call the file *.thor or Thorfile and place it in your current directory, any directory above you, or tasks/*.thor, you can then invoke the thorfile in any of the following ways:

$ thor -T
Tasks
-----
amazing:describe NAME [--forcefully]   say that someone is amazing
amazing:hello                          say hello

$ thor amazing:hello
Hello

$ thor amazing:describe “This blog reader”
This blog reader is amazing

$ thor amazing:describe “This blog reader” –forcefully
THIS BLOG READER IS AMAZING

You can also install local tasks or remote tasks to your system thor cache and make them available anywhere:

$ thor install task.thor
Your Thorfile contains:
# module: random

class Amazing < Thor
  desc "describe NAME", "say that someone is amazing"
  method_options :forcefully => :boolean
  def describe(name, opts)
    ret = “#{name} is amazing”
    puts opts["forcefully"] ? ret.upcase : ret
  end

  desc “hello”, “say hello”
  def hello
    puts “Hello”
  end
end
Do you wish to continue [y/N]? y
Storing thor file in your system repository

$ thor installed
Name      Modules
—-      ——-
random    amazing

Tasks
—–
amazing:describe NAME [--forcefully]   say that someone is amazing
amazing:hello                          say hello

$ thor amazing:hello
Hello

… same as above …

You can also specify a URL instead of a file name; like sake, thor uses open-uri to get the files. You uninstall or update thor modules based on the short name that was provided; if # module: name exists at the top of the file, thor will use that by default. You can also use thor install task.thor --as my_short_name. If you don’t provide a short name, thor will ask for one.

Later, you can do thor update short_name and thor will remember where you got the module from and try to update it. thor uninstall short_name will remove the module from your list of installed modules.

Of course, thor -T (or thor list) will list local tasks and system-wide tasks in the resulting list, so you don’t need a separate tool to track your thortasks, and a local task can be made into a system task trivially.

Finally, thor itself is self-hosting; the thor runner uses the Thor superclass. As a result, I added some more features to the superclass as I built the runner:

• You can map short names to their full name: map "-T" => :list, which is why thor -T and thor list are identical
• You can provide additional options that get passed in as a Hash (method_options :as => :required). The available option types are :required, :optional, and :boolean. The resulting hash is passed in as the final parameter to your method and the pretty-printed help automatically includes them in the usage screen.

Take a look at the thor repository on github, and specifically, the thor runner for more information on how it all fits together.

benchwarmer

Benchwarmer is an improved DSL for doing benchmarks (hat tip for the name to br0nette). It provides options for grouping, and produces output like:

Running the benchmarks 100000 times each...

                         Option 1 |   TWO | Option 3 |
 -----------------------------------------------------
 Squeezing with #squeeze     0.15 |  0.15 |     0.14 |
              with #gsub     0.38 |  0.35 |     0.36 |
 -----------------------------------------------------
 Spliting    with #split     0.43 |  0.51 |     0.61 |
             with #match     0.29 |  0.35 |     0.38 |
 -----------------------------------------------------

You get that output by doing:

  Benchmark.warmer(TIMES) do
    columns :one, :two, :three
    titles :one => "Option 1", :three => "Option 3"      

    group("Squeezing") do
      report "with #squeeze" do
        one { "abc//def//ghi//jkl".squeeze("/") }
        two { "abc///def///ghi///jkl".squeeze("/") }
        three { "abc////def////ghi////jkl".squeeze("/") }
      end
      report "with #gsub" do
        one { "abc//def//ghi//jkl".gsub(/\/+/, "/") }
        two { "abc///def///ghi///jkl".gsub(/\/+/, "/") }
        three { "abc////def////ghi////jkl".gsub(/\/+/, "/") }
      end
    end

    group("Spliting") do
      report "with #split" do
        one { "aaa/aaa/aaa.bbb.ccc.ddd".split(".") }
        two { "aaa//aaa//aaa.bbb.ccc.ddd.eee".split(".") }
        three { "aaa///aaa///aaa.bbb.ccc.ddd.eee.fff".split(".") }
      end
      report "with #match" do
        one { "aaa/aaa/aaa.bbb.ccc.ddd".match(/\.([^\.]*)$/) }
        two { “aaa//aaa//aaa.bbb.ccc.ddd.eee”.match(/\.([^\.]*)$/) }
        three { “aaa///aaa///aaa.bbb.ccc.ddd.eee.fff”.match(/\.([^\.]*)$/) }
      end
    end
  end

Most of that is optional; you can get usable benchmarks by stripping the DSL down to:

  Benchmark.warmer(TIMES) do
    report "squeezing with #squeeze" do
      "abc//def//ghi//jkl".squeeze("/")
    end
    report "squeezing with #gsub" do
      "abc//def//ghi//jkl".gsub(/\/+/, "/")
    end
  end

which produces:

                         Results |
----------------------------------
 squeezing with #squeeze    0.15 |
    squeezing with #gsub    0.34 |
----------------------------------

It is available at github. I will add the appropriate stuff so you can do
gem install wycats-benchwarmer. For now, you can just check out the git repo and do rake install.

I extracted this out of the benchmarks I was doing as I was building…

10x Faster Rails and Merb Inflector

On the plane over to Dallas Tech Fest, I thought it would be nice to try and improve the performance of the Rails Inflector, which is currently pretty slow (albeit probably not a bottleneck). Merb already uses the Facets English Inflector, which is 2x or so faster, but I was pretty sure I could do even better.

When I analyzed the English Inflector, I noticed a few things:

• They were doing something similar to Rails looping over a list of regexen and picking the correct ones
• Without exception, the correct choice was the longest string that matched the end of the word.
• Matching a string (like fooses) against a regex with (foo|foos|fooses) will always match the longest string
• Neither Rails nor English were caching the resulting words, which don’t change, and in the case of Inflecting Rails models and controllers, are a small universe of total words

As a result, I did two optimizations:

• I packed all of the regexen into a single regex, and got rid of the sort-by-longest-string code. I then did a simple sub! against the word, pulling the results out of the rules Hash (that already existed in English)
• English already cached irregular words (its first step was to look in the irregular words hash for the word in question), so I simply extended this cache to include any word already found.

Between these two optimizations, I was able to get around 10x over Rails, and got a huge boost for simple pluralization words (not so much for things like “person” => “people”). Rails also caught a bunch of cases in their tests that were not supported by English, so I added support for things like capital versions (”Person” => “People”) and partial words (”foo_child” => “foo_children”).

Here are the benchwarmer results:

                                         OLD  | NEW   | RAILS
Simple: account => accounts    Singular  0.16 |  0.02 |  0.25
                                 Plural  0.14 |  0.03 |  0.24
-------------------------------------------------------------
Simple: American => Americans  Singular  0.16 |  0.02 |  0.27
                                 Plural  0.16 |  0.31 |  0.27
-------------------------------------------------------------
Abnormal: dwarf => dwarves     Singular  0.07 |  0.04 |  0.17
                                 Plural  0.06 |  0.03 |  0.17
-------------------------------------------------------------
Abnormal: hero => heroes       Singular  0.05 |  0.03 |  0.20
                                 Plural  0.06 |  0.02 |  0.21
-------------------------------------------------------------
One Way: cactus => cactuses    Singular  0.11 |  0.02 |  0.26
                                 Plural  0.07 |  0.02 |  0.26
-------------------------------------------------------------
One Way: wife => wives         Singular  0.11 |  0.02 |  0.16
                                 Plural  0.13 |  0.03 |  0.14
-------------------------------------------------------------
Uncountable: fish => fish      Singular  0.03 |  0.02 |  0.03
                                 Plural  0.02 |  0.02 |  0.03
-------------------------------------------------------------
Exception: person => people    Singular  0.02 |  0.03 |  0.09
                                 Plural  0.03 |  0.02 |  0.11
-------------------------------------------------------------

It does break back-compat a bit with Rails, as the mechanism for adding new rules is simpler in order to be compatible with English’s faster inflector algorithm. I also had to remove Inflector#clear, which I wasn’t sure anyone was actually using (it allowed the clearing of very specific types of rules, which can no longer be supported as irregular words and regular singularization/pluralization rules are dumped in the same list for efficiency).

The new way of defining rules is:

Inflector.inflections do
  # One argument means singular and plural are the same.

  word 'equipment'
  word 'information'
  word 'money'
... snip ...
  word 'Swiss'     , 'Swiss'
  word 'virus'     , 'viri'
  word 'octopus'   , 'octopi'
... snip ...
  rule 'person' , 'people', true
  rule 'shoe'   , 'shoes', true
  rule 'hive'   , 'hives', true
  rule 'man'    , 'men', true
  rule 'rf'     , 'rves'
  rule 'ero'    , 'eroes'
... snip ...
  singular_rule 'of' , 'ofs' # proof
  singular_rule 'o'  , 'oes' # hero, heroes
... snip ...
  plural_rule 's'   , 'ses'
  plural_rule 'ive' , 'ives' # don't want to snag wife
  plural_rule 'fe'  , 'ves'  # don't want to snag perspectives

All of the inflector tests still pass in Rails, with the exception of the #clear tests, which were too coupled to the old implementation to salvage (they actually introspected into specific ivars).

The Rails modifications are available on my Rails branch on github. I hope to be able to push
the changes upstream if the Rails core folks are amenable :).

OSX Window Resizing Tools

I was going crazy trying to figure out a way to cordon off a section of my screen for screencasts (the center 800×600 for instance), and ended up in crazy AppleScript-land. I ended up with two useful scripts:

• center, which takes any window, resizes it to a provided size, and centers it on the screen
• maximize, which takes any window and maximizes it to fill the screen (even for crazy-zoom-windows like Safari)

Both scripts take drawers into consideration, so you can resize a window like TextMate to the correct size.

It is available at github and comes with a convenient raketask for installing
that will compile and copy your scripts into the appropriate folders. It also comes with a raketask that will install FastScripts Lite, which will
allow you to bind keys to these scripts (see the README for full details).

http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/DevelopersNew.htm#dom

Yes.

That’s right.

“Selectors are a query language for searching and “selecting” tags (elements) within a webpage. They are most commonly seen in CSS to “select” a group of elements to which certain properties will be applied:

Selector{
   property: value;
   property2: value;
}

In Internet Explorer 7 there is no way of “executing” the selector independently of CSS. Internet Explorer 8’s implementation of the Selectors API is based on the W3C Working Draft: http://www.w3.org/TR/selectors-api/”

Yes. You read that correctly. To the extent of IE8’s support for CSS2.1 (which should be relatively complete, according to their announcement), it will be possible to use the standards-compliant querySelector and querySelectorAll in IE to get collections of elements at native speed. This means fast class-name lookup, fast attribute lookup, and much much more.

Here’s a lame example of its use from an IE8 whitepaper:

function doValidation ()  {
// Retrieve the required elements by using Selectors
   // Selects all the form fields with 'required' classes
var reqs = document.querySelectorAll(".required");
   // Set the flag to false by default
var missingRequiredField = false;
// Validate that the form data is not empty
for (var i = 0; i < reqs.length; i++)  {
if (reqs[i].value == "")
         missingRequiredField = true;
   }

Yep. It is what it looks like. Finally, the days of slow IE selectors may be coming to an end. And finally, one where MS is ahead of the curve (in fact, a lot of the IE8 improvements are pretty neat and forward-looking; I recommend taking a look at it)

This time, we’ll talk about two new features added since jQuery 1.2: Setup and teardown for events and the element data store. First up, the element data store:

Prior to jQuery 1.2, data was added to elements via expandos. If, for instance, d was an element, and we wanted to add some data named “foo” with the value “bar”, we would do d.foo = "bar". Simple enough. But there are two major issues:

• Other libraries, plugins, or widgets might try and use the foo name. We could try and obfuscate the name (jQuery 1.0 used $events as the expando name for the events array on an element), but there was still a chance that another library could accidentally use the same name. In fact, that’s exactly what happened. MooTools inadvertently used $events, and people who tried to use both libraries got hosed.
• IE’s garbage collection gets all flummoxed under certain circumstances when an element is removed but its expandos still have references to live objects.

The solution, which jQuery adopted for 1.2, is to create a new data store that’s independent of the element and in the jQuery namespace, and which jQuery garbage collects itself when you remove the associated elements. This provides a mechanism for tagging elements with information that can then be used by different modules in your program. While jQuery uses it to track which events belong to which elements, it can also be used for other purposes.

For instance, the jQuery metadata plugin allows you to specify data to be stored in the data store in your markup. Here’s an example:

The markup

<div data="{foo: 'bar'}">Some div element is here</div>

The code

$.metadata.setType("attr", "data");
$("div").metadata().foo == "bar"

The metadata plugin produces a thin sheen over the data-store, allowing you to pass information into the store via markup. That might be quite useful for plugins, to allow your users to specify options for your plugin without needing to write any special code. For instance, you could write this code in your plugin:

Markup

<div class="myPlugin" data="{myPlugin: {option1: 12, option2: "stringyString"}}">Some Text</div>

The Code

$.metadata.setType("attr", "data");
jQuery(function($) {
  $("div.myPlugin").each(function() {
    $(this).myPlugin($(this).metadata().myPlugin);
  });
});

This is assuming, of course, that there is some $.fn.myPlugin that takes option1 and option2 as options. This technique allows you to put the initialization code in your plugin itself and let the user interact with it in fairly high-level ways via markup. The TableSorter plugin makes use of this technique.

But you can use the data store for other purposes as well. In particular, you can interact directly with the data store by doing $.data(el, “key”, “value”) to set a key in the store, or $.data(el, “key”) to retrieve a key. jQuery 1.2.3 will also add a new shortcut (which we’ll discuss in more length in the next post in this series), which will allow $(”div”).data(”key”).

I use this technique in the autocomplete plugin to tag a keystroke as “final” (hitting escape, for instance, should not trigger a new dropdown if it’s used to cancel the autocomplete). Even though the autocompleter is in a separate module from the event code that triggers the autocompleter, this information can be tagged onto the element so it’s accessible from any module.

Setup and Teardown

Setup and teardown lets you further customize event binding. In effect, setup and teardown functions are called immediately before an event is bound (and immediately before an event is unbound), allowing you to preform processing. Returning true from the setup function causes it to get bound using the browser’s native handlers, instead of the jQuery event system (don’t worry about this; it’s extremely rare). Let’s take a hypothetical activate.myPlugin event.

The Code

$.event.special["activate.myPlugin] = function() {
  /* “this” is the element being bound */
  /* do some processing */;
}

Later, when you do $("div").bind("activate.myPlugin") the special method will get run. This allows your plugin’s users to add some processing to when your plugin gets bound to an element, without having to override the plugin binding method.

Next up: New features that will be introduced in 1.2.3, and bringing this all together :)

It’s not exactly OO, which is what a lot of people are used to; it’s more like a publish/subscribe model, with points of modularity added via message passing. That’s because jQuery provides a pretty kick-ass system for custom events (events that are not built-into the browser), including a mechanism to subscribe to such events and a mechanism to trigger (i.e. publish) the events, with custom data.

It also provides the potential for setup and teardown for both browser and custom events, as well as a central data store for persistent data that would traditionally be attached directly to an element. This solves both the memory-leak issue (jQuery manages garbage collection of objects in the store that are no longer valid because the DOM element doesn’t exist anymore) as well as a crucial compatibility issue (we don’t store the data in the element itself, so we work fine with other libraries that do, or other libraries that have their own store in their own namespace).

Events

If you use jQuery, you already know about browser events:

$("div").click(function() { /* code here */ });

That’s a shortcut for:

$("div").bind("click", function() { /* code here */ });

What you probably don’t know is that you can also bind your own custom events:

$("div").bind("clickeroo", function() { /* code here */ });

That probably doesn’t seem all that useful until you realize you can also trigger these custom events:

$("div").trigger("clickeroo")

or even:

$("div").bind("clickeroo", function(e, data1, data2) {
  // some stuff that uses data
});
$("div").trigger("clickeroo", [dataObject1, dataObject2]);

And finally, you can bind custom events with namespaces:

$("div").bind("activate.dialog", function(event, options) {
  // some stuff that uses options
});

Triggering activate or activate.dialog will trigger the event, and because all JS arguments are optional, the options argument will work whether or not the core event was triggered with the additional data.

Where does this bring us?

So I claimed earlier that this provides us with a useful tool for modularity. If you’ve been paying attention, and like me, have run into some modularity ceilings, you should be realizing some of the possibilities here. Effectively, what you have is a publish/subscribe model for events. If I create a dialog plugin, I don’t have to have a massive options hash to provide a callback for the dialog opening, the dialog closing, the dialog resizing, etc. All I need to do is blindly trigger open.dialog, close.dialog, resize.dialog, etc. and allow the user to subscribe to those events if necessary. This even allows for meta-plugins that simply subscribe to events published by the main plugin and extend them. This is the approach I take in my autocomplete plugin, which publishes “autocomplete.activate”, “autocomplete.cancel”, and “autocomplete.selected” events.

My plugin also subscribes to the “updateList.autocomplete” event, which allows outside code to provide a list for the autocompleter at any time, without having to know how the internal autocomplete code works. In fact, the Ajax extension to the autocomplete plugin simply registers a callback for the call to getList that the plugin calls, which publishes an updateList.autocomplete event with the appropriate data when done.

In the end, this allows you to create self-contained modules in your application that communication with each other by providing public publish and subscribe points for interaction. In the case of the autocomplete plugin, all the events are published onto the input element, and external interfaces subscribe to events published to that element. This allows multiple autocomplete plugins on a single page that don’t need to use a single message bus. However, for more global events, you can publish/subscribe to/from the window or document object, which can provide a more global event bus.

Next time, I’ll talk about the setup and teardown methods for custom events, as well as using the element data store to store data about an element that needs to be shared between modules.

First up, we’re closing in on Merb 1.0. The next major release will be numbered 0.9, and will be the point release immediately prior to 1.0. In order to help make Merb even more modular and tight, Merb 0.9 will be broken up into a merb-core gem and a package of merb-more gems. The entire package will still install via gem install merb, and will be fully maintained by the core team. However, in Merb.next, it’ll be trivial to leave off chunks of functionality that you don’t want.

Merb Core, which we’re working on right now (you can follow our progress at Git Hub), will be the tight core of the framework, just enough to run basic web services and simple web sites. It’ll be possible to use Merb Core for a single-page app (a la Camping or Sinatra) or an app with a full-blown application structure (like Rails or current Merb).

Merb 0.9 will also tie up a bunch of loose ends, not shying away from breaking things in order to give Merb 1.0’s API as much longevity as possible. At the same time, we’re trying to make the upgrade path from Merb.current to Merb.next as painless as possible.

In an effort to keep Merb core really tight, we’re also adopting some more formal programming and documentation techniques that will make working on and using Merb much easier:

• All methods (public and private) are required to provide a clear method signature, including the types for any parameters, and the possible values for any options hashes, as well as return types and other information (see below for an example).
• Methods can be tagged @public, which means that changing them will break the public API. Methods can also be tagged @semipublic, which means that they’re used in other parts of the framework and possibly the test harness. This’ll aid future refactoring, because methods that are not public or semipublic can be reimplemented at will as long as the test suite still passes.
• We’re removing all hardcoded paths from the framework. This means that Merb will scale from a single-page app to any application structure you want. You can even specify how to name template files (you can go from the traditional controller/view.mime.type or controller.view.mime.type or even view.mime.type for a single controller app)
• We’re splitting our test suite into public and private tests. Public tests test the public API, while private tests test things like the Request object. Public tests are required to use only methods in the public or semipublic API, so they should still pass after major refactors.

Merb Core is also based on a Rack adapter now, so it’ll work out of the box with Mongrel, Evented Mongrel, FCGI, regular CGI, thin, webrick, and Fuzed, as well as any server you can write a rack adapter for. And fear not, you’ll still have access to the raw mongrel request if you want to do fancy stuff like streaming or deferred rendering outside the mutex.

Here’s an example of the new documentation standards:

  # Render the specified item, with the specified options.
  #
  # ==== Parameters
  # thing<String, Symbol, nil>::
  #   The thing to render. This will default to the current action
  # opts<Hash>:: An options hash (see below)
  #
  # ==== Options (opts)
  # :format<Symbol>:: A registered mime-type format
  # :template<String>::
  #   The path to the template relative to the template root
  # :status<~to_i>::
  #   The status to send to the client. Typically, this would
  #   be an integer (200), or a Merb status code (Accepted)
  # :layout<~to_s>::
  #   A layout to use instead of the default. This should be
  #   relative to the layout root. By default, the layout will
  #   be either the controller_name or application. If you
  #   want to use an alternative content-type than the one
  #   that the base template was rendered as, you will need
  #   to do :layout => “foo.#{content_type}” (i.e. “foo.json”)
  #
  # ==== Returns
  # String:: The rendered template, including layout, if appropriate.
  #
  # ==== Raises
  # TemplateNotFound::
  #   There is no template for the specified location.
  #
  # ==== Alternatives
  # If you pass a Hash as the first parameter, it will be moved to
  # opts and “thing” will be the current action
  #
  #—
  # @public
  def render(thing = nil, opts = {})
    <snip>
  end

Some description: The render method takes two parameters, a “thing” to render and an options Hash. The “thing” can be a String, Symbol, or nil. The options hash takes :format, :template, :status, and :layout options, which are described under Options. Th :status option must respond_to? to_i and the :layout options must respond_to? to_s. It returns a String (the rendered layout), and raises a TemplateNotFound if the template specified is not found. It is part of the @public API.

The documentation format will be itself documented as part of the Merb Core release, and we hope to write a parser that uses RDoc to spit out just the public API (leaving out public methods that are not marked @public).

The public test suite itself is also designed to provide a useful starting point for Merb plugin authors; here’s an example:

  # @public
  it "should accept template-type registrations via #register_extensions" do
    Merb::Template.register_extensions(Merb::Test::Fixtures::MyTemplateEngine, %w[myt])
    Merb::Template.engine_for(”foo.myt”).should == Merb::Test::Fixtures::MyTemplateEngine
  end

All in all, it’s going to be damn tight, formal, and grokkable. I plan to release some code traces once 0.9 is done that trace the path of a request through the Merb framework, so you can grok exactly how requests go through the pipeline and are eventually rendered.

Good Coding and Good Luck!

It’s taken a lot of time, and focus, and while it’s been a great experience, I’m also looking forward to being able to once again put my full energy into the various Open Source projects I’m involved in (including jQuery, of course). We’re reviewing typeset PDF’s of what looks to be just about ready to print — there’s light at the end of this tunnel!

The book is set to print in early to mid-January; as a final push before publication, Manning is offering 30% off until December 31st, with the code JQM30. Though the book is also available on Amazon.com, among other places, Manning is the only place you can also get the e-book, which at least for me, is really important.

Thanks to everyone who’s been there for me in this crazy busy time, and for everyone who’s had to grin and bear it while my focus was split. I’m almost done!

• a massive rewrite that successfully handles closing the window during a grep
• some UI tweaks
• an all-around improvement to the underlying code

I am also in the process of adding support for skipping certain directories (the current version skips .svn directories by default, but I want you to be able to turn on and off skipping Rails directories).

Download the bundle today!

Well… except for one little thing. Mail.app has threads, but it does not thread Sent Mail in with Received mail. In Gmail, on the other hand, inbound email gets threaded with outbound email, so I get a nice breakdown of the actual discussions I’ve been having. Devoid of outbound context, the threads are frequently confusing or meaningless.

The workaround I came up with is to create a new Smart Folder that includes Inbound email and Outbound email (Inbox and Sent Items). The Smart Mailbox, in threaded mode, correctly handles putting all of the email together. The little caveat is that outbound email that was not a reply to something appears in this view too (it does not appear in Gmail), but I think I actually prefer that mode of operating.

The new version of the Wycats bundle has the following changes:

• I am now using a utility window, so the search window always remains in front
• I am now tracking open windows, so if you have an open window, another one doesn’t open
• I track all available exit conditions and correctly exit the event loop
• Other bugfixes and tweaks

Download version 1.0.1 today!