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

OS X Lion brings dramatically redesigned versions of the classic iCal and Address Book applications. Many people, or at least some important decision makers inside Apple, are very happy with these changes. Other folks, such as myself, believe they look and behave like crap.

When I first saw the Lion version of iCal, my eyes were drawn to the obnoxious bits of paper that cling to the top of the window, artificially and pointlessly leaving the debris that you might find on a real-life calendar with removable paper sheets:

As Cathy Shive pointed out in her NSConference talk on user interface metaphors, the presence of junk like this in an application is at best useless, at worst distracting and detrimental to the usability of the application. I remember her saying in her talk, before Lion’s iCal had even been presented in a private developer beta, that little things like paper scraps in an application are particularly annoying because she always wants to try to pick them off just as she would with a physical object.

Lion has given me the opportunity to empathize deeply with that concern. I hate those cruddy paper bits, and I can’t pick them off! Or can’t I?

To clean up your copy of iCal on Lion:

1. Select the iCal application in the Finder and press cmd-D to duplicate (make a backup, for safe keeping).
2. Control click the application icon and select “Show Package Contents.”
3. Navigate to Contents/Resources/
4. Select “CanvasTopTile.png” and open it up in Acorn or another, less attractive image editor. Or download my edited version and replace the original file.
5. Select the paper bits and “clean them up” by deleting them.
6. Reopen iCal, and bask in the glow of your clean white calendar:

Granted, this only fixes the paper bits. You’re still stuck with that horrendous tan leather toolbar. But at least that doesn’t beg to be picked at. It’s worth noting that the tan leather can also be tweaked by editing a variety of other image resources in the bundle. It’s trickier because many of the graphical components of the toolbar are designed to blend with the leather background, so you’ll end up having to change quite a few of the images.

I’m reminded of another great observation Cathy made in her talk: when you make very stylistic choices like this for a user interface, you dramatically increase the variety of reasons that the customer can be repulsed by the design. What if I don’t like leather? What if I don’t like tan leather? What if I prefer a running stitch to an outline stitch? You can argue that matte grays and subdued color gradients may invite the same controversy, but there’s a reason they are so common in user interfaces: because they’re far less likely to distract from the form and function of the application itself.

Addendum: Updating the iCal code signature. Thanks to rentzsch and daagaak on Twitter for pointing out that editing the resource will break the “code signature” on the application, put there by Apple to assure users that the application 1. Was developed by Apple, and 2. Has not been modified by anybody but Apple. You can re-sign the application after tweaking it, to put it back into a  “signed” state, albeit not by Apple. Hopefully this will prevent it from prompting you all the time about approving connections to services like MobileMe. From the Terminal:

 codesign -f -s - /Applications/iCal.app

This reveals how little things like tweaking an application’s resources have wider-reaching consequences than they used to. I’m pretty sure you won’t miss any functionality in iCal by using a self-signed copy of the app vs. an Apple-signed version. But I could be wrong!