I released FastScripts 2.6.1 today, which restores support for Mac OS X 10.4 and 10.5, and also includes a few bug fixes and enhancements.

One cool trick in 2.6.1 is the way FastScripts behaves when your scripts include “keystroke” commands to synthesize keyboard presses. In the past, these scripts were tricky to get right in FastScripts, because the synthesized keystroke would be mixed up with the very keys you had used to invoke the script. Now, FastScripts will suspend execution of any such script until you release the keys that were pressed to invoke the script.

FastScripts 2.6.1 Changes

• Prevent conflicts with synthesized keystroke commands and keyboard shortcuts
• Fix for situations where FastScripts became the front app after running a script
• Fix the built in on-screen display windows to grow in height to fit displayed message
• Restore support for Mac OS X 10.4 and 10.5

Unfortunately, this update is not available on the Mac App Store. Apple has now rejected it twice, citing the behavior of the app when it is used to run one of Apple’s own bundled scripts:

/Library/Scripts/Mail Scripts/Create New Message.scpt

This script is terrible to start with, but starting in OS X Lion, it simply doesn’t work. It fails with cryptic errors, and FastScripts faithfully reports them. Apple is rejecting FastScripts for the behavior of a faulty script that is bundled with OS X Lion.

The review process for App Store submissions is frustrating to start with: every release takes extra time and there is a great deal of uncertainty as to when an update will finally be made available to customers. I have to admit that sometimes the review team identifies serious bugs that I am glad to have fixed before releasing an app. But the benefit of that kind of review seems to be balanced by reviews like this one, where Apple’s own bugs are being cited as the cause for rejection my app.

I am confident that FastScripts 2.6.1 will eventually be approved for the App Store. In the mean time, any customer who owns the App Store edition can download and run the direct-sale version from my site.

For a very long time, MarsEdit has included built-in support for processing text with Markdown, so users who publish in that text-based format can see in MarsEdit’s preview window how the post will look after it’s published.

It’s becoming more and more common for folks who use and love Markdown to expect it to behave the way a popular superset of the language, MultiMarkdown, behaves.

When I asked on Twitter how people would feel about MarsEdit replacing the standard default Markdown filter with one that does MultiMarkdown processing instead, the responsive was enormously enthusiastic: people want MultiMarkdown.

Because I believe that for all MarsEdit users who currently enjoy Markdown support, changing to MultiMarkdown will either be a non-issue or a god-send, I plan to make this switch in an update soon.

While I was looking into the current state of MultiMarkdown I learned that since I last looked into it, is has transformed from a Perl-script version like the original Markdown, into a blazingly fast, pure C version. This intrigued me, because it would be fantastic if while upgrading MarsEdit’s Markdown support to support more features and please more people, it could also become orders of magnitude faster.

The first hiccup I noticed when examining the source code is that it depended heavily on an LGPL open source library called GLib. While the LGPL license would be acceptable to bundle within a standalone tool in MarsEdit, it feels like overkill, and frankly, I’d rather have a standalone MultiMarkdown binary that doesn’t require any outside dependencies.

So that’s what I spent the last day doing.

My fork of MultiMarkdown adds an Xcode project, and a small but important number of code changes to substitute for what GLib was formerly providing. The result is a standalone x86_64/i386 binary that accomplishes MultiMarkdown filtering on any Mac running 10.6 or higher.

If you want to test this fancy new MultiMarkdown filter in MarsEdit:

1. Quit MarsEdit
2. Download MultiMarkdown Beta Filter
3. Unzip, and copy the folder named “MultiMarkdownBeta” to:

   [Home] -> Library -> Application Support -> MarsEdit -> TextFilters

4. Relaunch MarsEdit

Your MarsEdit preview window should now have a “MultiMarkdown” option in the preview window text filter popup. Select MultiMarkdown and see how it works for you as you preview Markdown-formatted posts in HTML Text mode.

I expect this version will have some bugs, which is part of the motivation for getting the adventurous among you to give it a try. The best way to report bugs is  by email or a message in the support forums. But if you just have low-key comments to make, this blog post would be an appropriate location as well. Thanks for your help!

Update, July 28: I’ve made major performance and correctness changes in the past day, so if you are helping to test the new MultiMarkdown filter, be sure to grab the latest version and update the copy in your MarsEdit TextFilters folder.

One of the things missing from Lion’s full-screen support is a standardized keyboard shortcut for switching modes. Before Lion, it was entirely up to developers to implement the behavior, appearance, and activation mechanisms for entering full-screen mode. Now, we are treated to standard “Enter Full Screen” buttons on qualified windows, and with standard “Enter Full Screen” and “Exit Full Screen” menu items for toggling modes. But there’s still no standardized shortcut.

Early in my testing of Lion, I decided to fix this using Apple’s mechanism for redefining keyboard shortcuts of specifically named menu items. For me, Cmd-Ctrl-Return makes a good toggle shortcut for switching any given app or window between regular and full-screen modes.

To do the same on your OS X Lion machine:

1. Open System Preferences.
2. Click the “Keyboard” preference pane.
3. Switch to the “Keyboard Shortcuts” tab.
4. Click the “+” button to add new shortcuts for “Enter Full Screen” and “Exit Full Screen”.

I find myself more likely to embrace full-screen mode and switch in and out fluidly when I can do so with a standard keyboard shortcut.

Update: Eric Schlegel points out on Twitter that Cmd-Ctrl-F is the “standard” for full-screen mode, but that some Apple apps don’t follow the standard. Perhaps that would be a better choice for this global setting as well.

One of the UI concessions OS X Lion makes to a time-honored Microsoft Windows feature, is the addition window-resizing hotspots on all edges of a given window. Traditionally, Mac users have been limited to resizing windows only through the use of the “Zoom” button in the title bar, or by clicking and dragging the resize control at the bottom-right corner of a window.

Now you can grab any edge of a window and grow or shrink it to suit your wants. What I didn’t notice until today, however, are a few interesting variations on window resizing that are facilitated by pressing a modifier key while resizing.

Hold the option key while resizing to cause changes in the  window’s width or height to be made in equal measure on each side of the window. For example, clicking and dragging the right edge of a window with option depressed will cause the left side to grow or shrink in mirrored fashion. For lack of a better term, I’ll call this balanced resizing.

Hold the shift key while resizing to impose constrained resizing. Whatever direction you grow or shrink the window, adjustments will be made so that the ratio of height to width remains the same.

These are some pretty geeky resizing modes. I don’t foresee using them particularly often, but it’s interesting to know they are there.

(I did some preliminary Googling before sharing this, and didn’t see any documentation come up. I’ve since noticed that Matt Gemmell already shared this tip in a Twitter update.)