It’s hard to believe FastScripts is just over ten years old. When I first started developing the app, one of my primary goals was to improve upon the relatively slow launch and execution time of scripts when using Apple’s own built-in script menu. At the time, my analysis suggested that the sluggishness was primarily due to the time spent loading the script from disk into memory, and in launching a separate helper app to carry out execution of the script.

To avoid this slowness, FastScripts adopted a strategy in which scripts are loaded into memory once, and kept ready to fire again at a moment’s notice. This, combined with support for global and application-specific keyboard shortcuts, opened a whole new world of opportunities for streamlining workflows with frequently reused scripts.

The approach comes with some drawbacks, however. For example, FastScripts can only run one script at a time. So if a script takes a long time to finish, it can be very frustrating to be locked out of the ability to run other scripts. Another issue is that occasional issues with Apple’s AppleScript support make it possible for a script to hang indefinitely or even crash. If this happens in the context of FastScripts running a script, then obviously it’s FastScripts itself that ends up hanging or crashing.

For a long time I have considered the possibility of changing FastScripts so that it runs scripts in a separate process. It already does this by necessity for shell scripts such as Ruby or Python, but I have clung to the belief that doing so for AppleScript would eliminate one of the app’s major advantages.

I use FastScripts myself to run a variety of extremely terse scripts. For example I have scripts that open favorite web sites, activate specific applications, or simply play and pause iTunes. It would be extremely frustrating if any of these scripts exhibited even a slight delay.

I am no longer convinced that the decade-old strategy of avoiding on-the-fly loading and running of scripts is providing any significant performance advantages. Macs have gotten faster in so many respects: faster RAM, faster disks, and faster and more numerous CPUs.

I have been experimenting myself with a version of FastScripts that runs every AppleScript in a separate process, and have experienced no noticeable delays. And now when I do occaionally run a script that takes several seconds, or even minutes to run, I can fire it off with FastScripts confident that it will be ready to immediately run another script.

If you are a FastScripts user and this sounds intriguing, the good news is you can try it out today. Just make sure you’re up to date with version 2.6.5 from the Mac App Store or direct from the FastScripts home page. Because I’m still tentative about the performance, by default FastScripts continues to run scripts with the old, in-process behavior. To enable the new separate-process functionality, just set this “secret” preference key in the Terminal:

defaults write com.red-sweater.FastScripts RSScriptingPreferSeparateProcesses -bool YES

If you do try this out and you also find performance is unaffected, please let me know in comments below. On the other hand, if you see a significant slowdown, that would be useful to know as well. And in case it’s not obvious, you can revert to FastScripts’s old behavior by re-running the line above with “NO” in place of “YES”. I will consider defaulting to separate-process execution in a future update, assuming performance is good across the board.

In adding this functionality to FastScripts, I also considered that performance might not be great for all users, but there would nonetheless be cases where running a separate process would be preferable. For example if you have one script that you know will always take a long time to complete, you might want FastScripts to only bother with a separate process for that script. You can instruct the app to run it in a separate process by implementing a custom AppleScript handler in the script itself:

on redSweaterScriptingPrefersSeparateProcess()
	return true
end redSweaterScriptingPrefersSeparateProcess

Now when FastScripts runs the script, you won’t have to wait around for it to finish. Just fire and forget!

MarsEdit 3.5.9 is now available. This is a free update for licensed MarsEdit customers. The update will be submitted to the Mac App Store today and will be available there when Apple approves the update.

This is quite a significant update, in spite of it being entirely composed of “bug fixes.” I’m still working a major update to MarsEdit that will accommodate the Mac App Store’s sandboxing requirements. Until that is ready, I’ll keep fixing bugs in the app but will not be able to add significant features.

MarsEdit 3.5.9 changes:

• Fix a bug from 3.5.8 that disabled draft support for Squarespace 5
• Fix a bug where uploaded images were not resized correctly on Retina Macs
• Fix a bug where the preview window could sometimes show the wrong blog’s theme
• Fix a bug that caused malfunctioning Screen Capture and Image import services in rich editor
• Fix a bug that caused unpredictable behavior with Paste contextual menu item
• Fix a bug that prevented URLs with apostrophes from being linked in rich text mode
• Fix a bug that could lock up the app if close box clicked on authentication panel
• Fix a bug that prevented favicons from being downloaded from some blogs
• Fix a bug where switching quickly to HTML Text mode after opening a post could clear the content
• Fix a bug where images would sometimes fail to load in main window preview
• Fix a bug where unchecking all categories for a post would not update categories correctly
• Fix a bug where ExpressionEngine authentication failures did not prompt the login panel to appear
• Fix a bug where the last change to an image’s name or size did not “stick”
• Fix a bug where some errors would display as simply “(null)” instead of with meaningful text
• Fix a crashing bug that could occur while editing the preview template
• Fix a bug that caused drawing defects in some preferences text fields

Enjoy!

Michael B. Johnson wondered out loud on Twitter about the possibility “focusing” on a single calendar in Apple’s default Calendar app for the Mac:

In Calendar on the Mac, is there a way to “mute” or “invis” all calendars but one? I have a sparse calendar, and many non-sparse ones…

— Michael B. Johnson (@drwave) January 16, 2013

In a nutshell, he wants to be able to go from his “usual” setup to zeroing in on just one calendar, and then back to the usual setup.

Folks chimed in with suggestions that almost hit the nail on the head, but not quite. For example if you hold the command key while clicking the enabled checkbox next to a calendar, it will toggle all your calendars on or off. So getting to the state of focusing on just one is fairly routine: just toggle them all off and then click one back on.

The problem is when you’re done focusing on the one calendar, unless your usual configuration is to leave all calendars checked, you’ll have a tedious task of checking each of the (possibly many) calendars you want to enable again.

This is a strictly theoretical problem for me, because I only have a few calendars, and frankly I don’t use any of them all that much. But Michael says he has around 25 calendars, about 20 of which he keeps enabled routinely. That could certainly get annoying!

When I see a problem like this that seems “unsolvable,” I become very curious whether there is a scripting based solution. Unfortunately the AppleScript dictionary for Calendar doesn’t seem to expose the “enabled” attribute of calendars. You can access the color or title of a calendar, but not the equivalent value of clicking that checkbox next to the calendar’s name.

I found a marginal solution in GUI Scripting, which I can use to inspect the various rows of the Calendars source list, to determine whether a named calendar is enabled or not, and to toggle its checkbox based on my own criteria. If this is the kind of thing that interests you, you might want to give the solution a look. Note that the script is designed to work on Mac OS X 10.8, and apparently does not work well on 10.7.

Click to download Toggle Calendar Focus.

What happens when you run the script?

If there are two or more calendars selected… the script assumes that you want to focus in on the single calendar that is highlighted in the Calendars source list. It checks the box for that calendar and unchecks all others. Before doing this it saves the names of all checked calendars to a temporary file.

If there is only one or no calendars enabled… the script assumes you would like to toggle “back to normal.” That is, it systematically checks the boxes next to all the calendars that were saved off above, and unchecks all others.

So in practice, you would select a calendar to focus on, and run this script to turn off all other calendars. Then, when you’re ready to go back to normal, just run the script again.

There are a variety of tools for running scripts like this but naturally I recommend my own FastScripts, which is free until you want more than 10 keyboard shortcuts. If you put the script in the Calendar-specific scripts folder:

[Home] -> Library -> Scripts -> Applications -> Calendar

Then it will appear in the FastScripts menu only when Calendar is the front-most app. You can also assign a keyboard shortcut that will only be active in Calendar.

I hope this solution is useful or inspires you to think about how you might tweak it to suit your own needs.

Update: the original version of this script required opening and editing a list of calendar names that should be “gone back to” when done focusing on a single calendar. The current version of the script instead assumes that when it’s focusing in on a calendar, it should save the list of all checked calendars, and restore that list when it toggling back.

One of the MarsEdit features that people really like is the simplicity of pasting a URL link into a post. Just copy a URL from anywhere, then press Cmd-Shift-A to transform the selected text in MarsEdit into a link.

Today a MarsEdit customer wrote with a more specific request: he would like to easily insert links to whatever page he happens to have open in Safari, while also using the title of the page as the link text. This is the kind of specialized feature that is less likely to show up as a built-in feature of MarsEdit, because if I added all the specialized features that might be handy here and there, it would quickly become overwhelming. But it’s the kind of thing where I’m very grateful for MarsEdit’s scriptability. Within a few minutes, I was able to share with this customer a script that does just what he wanted.

Click to download: Paste Safari Link script.

If you want to attach a keyboard shortcut to the script, you could use FastScripts, or you can add the script to MarsEdit’s Scripts folder, and then assign a keyboard shortcut using System Preferences:

1. From MarsEdit’s script menu, select “Open Scripts Folder”.
2. Drag the “Paste Safari Link” script into the folder.
3. Open System Preferences
4. Navigate to Keyboard, Keyboard Shortcuts, and select Application Shortcuts.
5. Add a new shortcut for MarsEdit, specifying “Paste Safari Link” as the menu title.

When invoked, the script will insert a link to the active Safari page’s URL, using the page’s title as the text of the link. If you want to use different text as the title of the link, the just type and select it in MarsEdit before invoking the script.