Next post Previous post

An hour of wolves and shattered AppleScripts

October 30, 2013 at 11:48 PM by Dr. Drang

A day may come when Mavericks doesn’t fail, when I forsake complaining to bond with it in fellowship. But this is not that day.

This weekend, after upgrading to Mavericks, I was writing a piece in Markdown and invoked one of my favorite scripts, the one that creates a reference-style link on the fly, putting the reference down at the bottom of the file and numbering it automatically. The script has been improved since I first described it; now the dialog box it brings up for the URL is pre-populated with the address of the frontmost Safari page.

URL dialog window

More often than not, this is exactly what I want to link to, so all I have to do hit the Return key and the link is made. Sometimes, though, the page I want to link to is not the frontmost Safari tab. In those situations, I can either

  1. Type the URL into the dialog box (not preferred).
  2. Paste a URL that I had oh-so-cleverly copied onto my clipboard for that very purpose.
  3. Use one of my URL TextExpander snippets to insert the URL of one of the other Safari tabs.

The problem I ran into under Mavericks is that neither Option 2 nor Option 3 worked—when I tried either one of them, my Mac just beeped at me. As this was a script that had been working just fine before the upgrade, it wasn’t hard to pin the blame on some as-yet unknown change in AppleScript.

I opened the script in the AppleScript Editor to see if I could figure out a workaround. To my surprise, the script worked fine when run from there. It was only when it was run from BBEdit’s Scripts menu1 that the problem occurred.

After putting together a minimal script that demonstrated the bug, I sent off an email to BBEdit, expecting to hear back from Patrick Woolsey, who’s always helped me before. I was surprised to get a response directly from the Chief Boner, Rich Siegel, who said the problem looked like it arose from a change in AppleScript’s standard additions, which is where the display dialog command lives. He suggested I send a bug report to Apple and said he’d follow up with their AppleScript developers. I filed a bug report right away, quoting some of his message to lend it more weight.

I’m sure the bug will get fixed more quickly with Rich’s support, but that doesn’t help me in the meantime. I use this script several times in every blog post, and I can’t imagine writing without it.2

The workaround turned out to be simple but disappointing. Instead of running the script through BBEdit, I now run it through FastScripts instead. For whatever reason (Rich gave an explanation in his message, but it was over my head), pasting and TextExpandering works when the script is run outside the BBEdit environment. I just copied some helper scripts from the WP-MD package into my local ~/Dropbox/bin directory and then made a few changes at the top of the reference link script to tell it where helper scripts are. A few minutes of work at the most.

What was disappointing was that I had spent a fair amount of time putting several scripts together into a single, portable package that could be used by anyone. Mavericks was forcing me to break that package up. It took only a few minutes to fix, but that fix undid hours of work I did in August.

It takes the heart of me.

Update 10/31/13
This will ruin my Aragorn bookends to the post, but I need to show you a better workaround I learned from Rob Trew. The command causing the problem is display dialog, which I usually think of as being part of AppleScript proper (because you don’t need to wrap it in a tell), but which is actually a command in the Standard Additions.

Standard Additions and display dialog

This is the key to Rob’s solution. Instead of having the line

applescript:
set myURL to the text returned of (display dialog "URL:" default answer fURL)

I should have

applescript:
tell application System Events
  activate
  set myURL to the text returned of (display dialog "URL:" default answer fURL)
end tell

My imperfect—and possibly just plain wrong—understanding of how this works is that putting display dialog under the aegis of System Events bypasses whatever conflict has arisen between BBEdit and the Mavericks version of Standard Additions.

Whatever the reason, the script is working again, and I don’t have to break up my WP-MD BBEdit package. Hurrah!

Full disclosure: Rob actually suggested a slightly different tell line:

applescript:
tell application id "sevs"

His reasoning behind this can be found in this thread in the OmniGroup’s forums. Basically, he argues that calling an app by name is less robust than calling it by its creator code because names are more easily, and more often, changed than creator codes. I went with

applescript:
tell application "System Events"

instead because it’s easier to read and the System Events name seems awfully stable.

  1. Yes, I always invoke it through a keyboard shortcut, ⌃L, but that’s a distinction without a difference. What’s important is that it didn’t work when run via BBEdit. ↩

  2. You’ve probably seen Brett Terpstra’s post about using “lazy” reference links in a style favored at TidBits. His script for pre-processing those links before sending them to a Markdown processor is really clever—much shorter than I expected it to be—but it’s basically just a means of assigning reference numbers to each link. It isn’t intended to help write the links in the first place. This isn’t a knock on Brett’s work. He’s solving a problem that the lazy link users have created for themselves. But I much prefer my script, which writes the link and assigns the reference number in a single step. ↩

Next post Previous post