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

This update is primarily a “bug fixes” release, that is to say, no new features. However, I am allergic to version numbers such as “3.5.10”, which was where MarsEdit was heading. I decided to jump to 3.6 with this release, on the basis of a bug-fix change with wider implications:

MarsEdit can now apply the preview filter as part of the publishing process.

This is primarily of interest to folks who write in HTML Text mode with a text filter such as Markdown, but publish to a blog that doesn’t support it natively. Now you can check a box in the blog’s settings to ensure that the preview filter runs when you publish, causing for example the Markdown content to be converted automatically to HTML as part of the publishing process. Given that MarsEdit supports custom preview filter scripts, the sky is the limit for how you choose to manipulate your post content as part of the publishing process.

Generally I strongly encourage folks to set up their blogs in such a way that Markdown can be used natively and preserved for later editing, but this is not always possible. This is a great option for folks who want the convenience of writing in Markdown but need to publish in HTML.

The change was actually made to address a change of behavior with Blogger, where historically plain text separated by newlines was automatically converted to paragraphs. They changed this behavior sometime in the past few months, so that the paragraphs are “crunched together” if you write in HTML Text mode and were relying on automatic line breaks. Using the new “Apply preview filter” feature, you can work around the bug by causing MarsEdit’s default “Convert Line Breaks” filter to process the content of your post as it is being published.

There are a number of other bug fixes in this release. Complete change notes below:

• Restore auto-configuration functionality for Blogger/Blogspot blogs
• Fix a bug where an authentication dialog was not appearing for some LiveJournal and Squarespace configurations
• Fix a bug that prevented Flickr short-name being used in Flickr page links
• Fix a bug that prevented undo from working in some editor fields
• Fix a bug that allowed rich text to be pasted into Tumblr quotation text field
• Fix a bug that caused Tumblr quotation source text to be treated as plain instead of as HTML
• Fix a bug where new image albums for Blogger were created with public permissions
• Fix a cosmetic glitch with the Date Editor panel

Enjoy!

Update: 3.6 had a bug that caused the flagship “apply preview filter” feature to fail on some blog types including WordPress and Movable Type. 3.6.1 is now available and should address the problem.

Recently something changed in the format of Blogger blogs such that MarsEdit’s method of “auto-configuring” is now failing. This does not affect existing configurations in MarsEdit, but any new Blogger blog added to MarsEdit will fail to connect with a cryptic “Invalid Blog ID” error.

I’ve added a workaround of the problem to the Red Sweater Forums. The long and short of it is the “API Endpoint URL” and “Blog ID” fields in MarsEdit’s configuration need to be manually corrected.

I am working on a permanent fix for the next update to MarsEdit.

As I noted last year, when Squarespace released version 6 of their popular web hosting service, they opted not to continue supporting 3rd party blog editors such as MarsEdit.

Luckily for fans of MarsEdit who were already hosting with Squarespace version 5, they left support in place, and it has remained mostly functional for the past several months.

A few weeks ago, the API support for Squarespace 5 stopped abruptly, but then resumed. Last week, the service stopped again, and has yet to be restored.

I have been in touch with Squarespace through their regular support channels, but they do not yet seem to appreciate the scope of the problem. In short: all Squarespace customers who rely upon 3rd party editors (not just MarsEdit) that use the API interface, were met with a sudden stoppage of functionality for those apps. The reason? The API through which the service is provided suddenly stopped working and instead redirects to a 404 landing page:

http://www.squarespace.com/process/service/PostInterceptor

To seamlessly restore API service for all Squarespace 5 customers, they need to “flip the switch back on” for this API, so that it connects customers with 3rd party clients in to their sites.

Squarespace’s customer support team has been patient while I try to explain the scope of the problem, and did share with me a workaround that I believe will allow all MarsEdit customers to “fix” their configurations in MarsEdit, regardless of whether they ultimately decides to fix the problem for all customers. To get things back to normal for your Squarespace 5 blog in MarsEdit:

1. Open MarsEdit
2. Click the Squarespace blog icon in MarsEdit’s main window.
3. Select Blog -> Edit Settings from the menu bar at the top of the screen.
4. Change the API Endpoint URL to:

   http://five.squarespace.com/process/service/PostInterceptor

   Note that this is identical to the malfunctioning URL with the exception that the “www.” has changed to “five.”

5. Close the settings window and Refresh the blog to confirm it works.

Note that because of another nuance of Squarespace’s API, if you are configuring a Squarespace 5 blog from Scratch in MarsEdit, you will be met with a confusing error message when it first tries to connect: “Internal Server Error.” This indicates that you need to manually enter your username and password. Select the blog in the main window again, and then choose Blog -> Enter Password from the menu bar.

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!