David Lynch

deviantART just upgraded to jQuery 1.3, and we found an undocumented jQuery change that broke some things.

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 really like “smart home” behavior in text editors. That is, I like it when pressing the “home” key first moves the cursor to the start of the indented text on that line, and then to the very beginning of the line on a second press.

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.)

I warn you in advance that this post does not end with a resolution of my problems.

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…

I recently saw one approach to the “what git branch am I on?” issue, which (if you’re using the bash shell) puts your current branch into your prompt.

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.

Del.icio.us rebranded to Delicious, along with a new URL. This happened a week or two ago.

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

So it’s fixed.