CriticMarkup was unveiled a little bit ago, and it was intriguing but not immediately useful to me at the time. Since then I’ve been playing with the MultiMarkdown Composer beta (available to owners of version 2), which includes a basic “change tracking” feature supporting full CriticMarkup syntax as you type. I’m sold.

The initial release of CriticMarkup included a preprocessor for Marked 1.5+, but given the uncertain release date of the next incarnation of Marked, I wanted to make it work with the standard custom processor feature of Marked 1.4. A few adjustments to the existing script and one dependency later it’s good to go.

First, go and explore the CriticMarkup syntax. When you have a document marked up and ready to preview, grab the custom processor script and put it anywhere in your user folder or subfolder. This version of the script requires that you have the MultiMarkdown binary (available via brew) installed at /usr/local/bin/multimarkdown. You can, of course, edit the script to use any external processor you like after CriticMarkup has done its thing.

Next, make sure that the script is executable. Run chmod a+x /path/to/critic.py, substituting the path to the script for the “/path/to” part.

Then, just enter the path to the critic.py script in Marked’s custom processor field under Behavior preferences. If you get the path wrong, the text will turn red to let you know. Enable the custom processor checkbox and hit “Save” at the bottom of that box.

Now, when you load a CriticMarkup document in Marked, you should see three tabs: Markup, Original and Edited. These let you see a view with changes inline, or see the document’s original state and how it looks with all changes accepted.

I really hope to see a time in the future when this system (or something similar) takes off for editorial work. I think it’s an excellent way of tracking changes and edits between two people. Properly used, it could handle quite a few sources of feedback. Combined with a system like Draft, it could kill Word. Someday…