The behavior of the :enabled selector changed. Before it selected all enabled form elements, now it selects all enabled and non-hidden form elements. This bit us, because we were using jQuery to assemble some form elements to submit over xmlhttprequest… and now some hidden fields weren’t getting included.

This means that if you were using :enabled, you now need to use :not(:disabled) to get the old behavior.

A bit of googling turned up that this is a deliberate change, to match the behavior of querySelectorAll in browsers that have implemented it. I’d disagree with the phrasing John Resig used, “more standards compliant”, since “enabled” has a specific meaning in the standards.

This should really have been in the release notes…

I am very happy to have found this. Now, I just need someone to write “NautilusGit”. (Or wait for the NautilusSVN project to do what they say they plan to, and extend it to cover multiple VCSs…)

I go out of my way to enable this behavior, where possible. For instance, I wrote a gedit plugin to get it working properly in gedit, the Gnome text editor.

Unfortunately, TextMate is a harder nut to crack. I worked out the following as a TextMate command, and bound it to command-left:

#!/usr/bin/ruby
current_line = ENV['TM_LINE_NUMBER']
current_column  = ENV['TM_LINE_INDEX'].to_i
whitespace_column = /^(\s*)/.match(ENV['TM_CURRENT_LINE'])[1].length + 1

column = if current_column == 0 or current_column > whitespace_column
           whitespace_column
         else
           0
         end

`open "txmt://open?line=#{current_line}&column=#{column}"`

It works, but is far too slow to be usable for me. There’s a perceptible lag of probably around 100-200ms between hitting the shortcut and the cursor moving.

I think this is an unavoidable limitation of TextMate’s approach to letting commands navigate within the file. It has to spawn a process to run the command, and the command then spawns a process to run the OSX command open which handles a “txmt://” protocol that TextMate has registered with the OS. There’s some inherent inefficiency there.

(Writing a command with pure shell scripting doesn’t help, incidentally. It’s slightly faster, but still not enough to be worth it.)

One problem with TextMate is that its built-in search is very slow, especially across a large project. Since I work with a full checkout of the deviantART source code, searches can take a while.

So I started using Ack in Project, a TextMate bundle that uses ack to search your project. (Ack is a nifty little tool that combines grep and find, along with a number of useful optimizations for searching checked-out source code.)

However, Ack in Project doesn’t expose a very useful part of ack’s functionality, which is the ability to search just particular filetypes. This has occasionally been a pain — some words appear commonly in PHP and JS files, but I only care about them in the PHP.

So I spent a little while this evening adjusting Ack in Project to let you choose a file type to search.

My version is up on github.

If you’d like to use it, do this:

cd ~/Library/Application\ Support/TextMate/Bundles
git clone git://github.com/kemayo/ack-tmbundle.git Ack.tmbundle

(It was my first time messing with tm_dialog, so I’m not necessarily confident about how I did it. But it works!)

For reasons relating to dynamic loading of javascript dependencies, I wanted to find a way to tell:

1. When a script tag finishes loading a file
2. Whether that file was successfully loaded

For various reasons, I didn’t want to add cruft into the files being loaded — no appending a function call to the end of every file, or anything.

Now, the finishes-loading case turns out to be pretty easy, albeit with some quirky cross-browser ramifications:

var eax, load;
eax = document.createElement('script');
eax.setAttribute('type', 'text/javascript');
eax.setAttribute('src', src);
load = function(e) {
    // FF/Safari get the `load` handler, IE gets the `readystatechange` handler.
    // IE doesn't fire 'load' for JS (but does for CSS...)
    if(!eax.readyState || eax.readyState == 'complete' || eax.readyState == 'loaded') {
        // IE6 stalls at 'loaded' sometimes
        alert('loaded!');
        // remove these listeners for everyone, because it's
        // easier than testing everything to find out whether it's needed.
        removeEventListener(eax, 'readystatechange', arguments.callee);
        removeEventListener(eax, 'load', arguments.callee);
    }
};
addEventListener(eax, 'load', load); // FF/Safari get this
addEventListener(eax, 'readystatechange', load); // IE gets this

It’s a horrible mish-mash of events, obviously, but it works. Insofar as it goes.

Working out whether the load was successful turns out to be the hard part.

In Firefox it’s very easy. The load event doesn’t fire if there are problems loading the JS file, and a error event fires instead. This is lovely.

In Safari the load event doesn’t fire if there are problems, but there’s no other sign given. So I could probably fake this with a setTimeout set to a reasonable length — not perfect, but good enough for most cases.

In IE the readystatechange event fires away regardless. It’s here that I’m stuck — I can’t see any way to tell, in the readystatechange handler whether the script tag was really loaded without problems.

Since IE represents an unfortunately large component of deviantART’s users, half-working failure detection isn’t going to cut it. Especially since all the developers mainly use Firefox/Safari, and wouldn’t expect IE to behave differently.

So for now I’m going with verifying that the script tag loaded something, and says it’s complete. I’ll keep my eyes out for a way to work around IE…

It’s probably a Firefox 3.1 quirk. But it’s still annoying.

There’s also tortoisegit for Windows. TortoiseSVN has always been one of the best things about SVN, so it’s good to see a clone pop up for git.

This is mostly good, but I discovered a problem as a side-effect of them improving their mouse support. Now that my mouse is auto-detected with all its buttons, the side-button no longer defaults to being a middle-click. I like having the side-button do middle clicks.

So, no problem, I thought. I’ll just go rebind it. There is doubtless something in the mouse settings that lets me adjust this — I mean, Windows generally handles this fine, so surely Ubuntu will be at least equivalent.

This turned out to not be true.

After a lot of searching, I found the community documentation for the Logitech Marblemouse USB, which (sort of) discusses how to remap buttons.

So I ran:
$ xinput set-button-map "Logitech USB Gaming Mouse" 1 8 3 4 5 6 7 2 9

This didn’t remap it, per se. It swapped clicking the mouse wheel and clicking the side-button.

(I’m not certain that this will persist through a reboot. I might need to meddle with .Xmodmap.)

It’s a weird place to be lacking what I consider basic functionality.

Incidentally, this new URL broke my delicious widget. I just noticed that a half-hour ago.

So it’s fixed.