If you are using emacs, you can use the :emacs_with_trace open command, and get the stack trace as a navigable compilation buffer (next to || below) the source file in a split frame. For this to work, you’ll need to add the following function to your emacs init:

See github for the code and README.

You can add filters that allow you to ignore some exceptions, and filters that allow you to scope the backtrace search. The backtrace scoping is useful for opening the last call in your application code when the exception occurs in a framework or lib.

If you are on MacOSX and have the growl gem installed, you will get a growl notification with the exception message when the file is opened.

Editors

Out if the box, the gem supports three editors (with the following open commands):

    :emacs => '/usr/bin/emacsclient -n +{line} {file}',
    :textmate => '/usr/local/bin/mate -a -d -l {line} {file}',
    :macvim => '/usr/local/bin/mvim +{line} {file}'

Note: if using emacs, you will need to be running emacsserver. To start the server: M-x server-start
or add (server-start) to your init.

Configuration

To configure, pass a block to the configure method:

    OpenException.configure do |oe|
      # open_with can be one of the built in editors (:emacs, :macvim, :textmate)
      # or a command to execute to open the file, where {file} and {line} will be replaced
      # with the file path and line number, respectively. See 'Editors' above for an example.
      # The default editor is :emacs.
 
      oe.open_with = :emacs
 
      # you can add exclusion filters to ignore exceptions. A filter can be an exception class to 
      # ignore, or a proc that is passed the exception, and should evaluate to true if the exception 
      # should be ignored. Be careful with using a class - it uses is_a?, so any subclasses of the
      # passed class will be ignored as well. The list of filters is [] by default.
 
      oe.exclusion_filters << SomeErrorClass
      oe.exclusion_filters << lambda { |exception| true if exception_should_be_excluded }
 
      # you can scope the search for the file:line to open with a filter as well. A filter can be a 
      # regular expression that is matched against the line, or a proc that is passed the line and 
      # should evaluate to true if the line should be used. The first line that any filter passes for 
      # will be the file:line that is opened. This is useful for opening the point in the stack just
      # before control passes out of your app code when the exception occurs in an external 
      # lib/framework. The list of filters is [] by default. 
 
      oe.backtrace_line_filters << %r{/app/root/(app|lib)} 
      oe.backtrace_line_filters << lambda { |backtrace_line| true if line_should_be_used }
 
    end

Rails Integration

The gem also alias chains in to rails’ ActionController#rescue_action_locally method to automatically open exceptions in development mode. The gem also adds the following filter to the :backtrace_line_filters to scope the opened files to the app:

    @%r{#{Rails.root}/(app|lib)}@

To replace or remove this filter, you will need to reset the :backtrace_line_filters in your configure block:

    OpenException.configure do |oe|
      oe.backtrace_line_filters = []
      oe.backtrace_line_filters << my_new_filter
    end

This has been tested with rails v2.3.5, but should work fine with 2.1 <= rails < 3. It may work with rails 3 as well, I just haven’t yet looked at rails 3.

Standalone/Other Frameworks

    # To manually open an exception, or wire it up in another framework, you call:
    OpenException.open(exception)
 
    # You can override the default (or configured) options by passing a hash as the second arg:
    OpenException.open(exception, {:open_with => :textmate, :backtrace_line_filters => [filter, another_filter])

The source is on github, and the gem is on rubygems.

So here it is. Its a package that allows you to comment out a block of ruby code from a keybinding (I’m sure there is code out there to do this already, but it was a fun learning challenge).

The main function is comment-ruby, which I have bound to C-:. If there is a region active, it comments out the region. If that region is less than five lines, each line is commented with ‘# ‘, otherwise the entire region is wrapped in =begin...=end. If the region is not active, the current line is commented out with ‘# ‘.

After a region has been commented out, the point (cursor) is set to the line above or below the region, depending on whether the point was at the beginning or end of the region when called.

Here is the code – it probably isn’t idiomatic lisp. If you have any suggestions on improving the code or making it more idiomatic, please let me know!

I’ve been using Kim van Wyk’s ack.el for a few months now, but was annoyed that I had to tell it the directory where to run ack, when in most cases I wanted it to run in the root of my Rails app. So I copied the ack function from ack.el and made one that only asks for the search pattern, then runs in the root of the app (provided by rinari’s rinari-root function). I then bound that function to C-c f a.

Here is the code:

Note: you will need rinari and ack.el loaded, and ack will need to be in your path.

ctags

Traditionally, the ctags/etags executable was used to generate lookup tables for vi/emacs respectively. ctag would create a tags file for vi, and etag would create a TAGS file for emacs. Unfortunately, the etags/ctags that ships with MacOS X does not parse ruby code. For that, you will need to use Exuberant Ctags. You can install Exuberant Ctags on MacOS via MacPorts with sudo port install ctags.

git hooks

There are some nice hooks that you can define for git to call after/before it performs certain actions. You can read the full list here. Hooks are defined by placing properly named executables into .git/hooks/ in your repo. The two hooks we care about here are post-merge and post-commit ( Update: the script has been modified to register for the post-checkout hook as well, based on a suggestion from Bryan Liles). The post-merge hook will get called after you do a git pull to merge from another repository, and post-commit is called after a local commit. An important thing to remember about these hooks (and anything else in .git) is that they will not be pushed to the remote repo. So if you develop on multiple machines, or want to share hooks with coworkers, you will need to install them in each local repo.

the kitchen sink

Here is the script I use to handle generating tags from ruby code explicitly, generating tags from a git hook, and installing the git hooks. It really should be two different scripts, but… well… isn’t.

You can read it and see what it does. To have it install the hooks in the current repo, call it with the -i@ option. If you use vim instead of emacs, you will need to remove the @-e option and change TAGS to tags on the ctags call.

Once it is installed, your tags will be regenerated after every commit or pull. You can manually regenerate the tags by calling the script from the repo base directory.

Update: to see a video of this script in action, check out Bryan Liles’ post on smartic.us.