maphilight 1.2

I finally got around to officially releasing maphilight 1.2.

This mostly just updates the official jquery.com release to the HEAD of the github project.

I’d been putting it off because I spent quite a while without easy access to a Windows machine with IE8 to test the fixes that people provided. But I switched back to Windows as my main desktop recently (mainly to play games), so that was resolved.

There’s not much in the way of changes:

  • IE8 works now
  • New “neverOn” option for use with metadata by Zach Dennis, which stops individual areas from ever being hilighted
  • Handles being called on the same area twice differently; now rebuilds the hilighted regions
  • …and I added an example of triggering the hilight from another element, since it’s one of the most commonly asked questions

Hopefully I’ll be able to post here a bit more now that I have some of that guilt for not updating off my shoulders. 😛

A jQuery 1.3 quirk that bit me

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…

Smart Home in TextMate

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

TextMate bundle: Ack in Project (improved)

I use TextMate for work. It’s a good editor, doesn’t get in my way, and I take advantage of relatively few of its nifty features.

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 Ack in Project tweak

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

Detecting failure

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…