There’s syntax highlighting, a preview window, and it can export to html. The best feature is the document outline, which is a joy for editing large documents. Plus you can use TODO tags and these get picked up as tasks, and an emacs-style text formatting tool.

If IDEs are your thing and you are using Eclipse, you might want to check it out.

1. the message URI
2. the message id wrapped in angle brackets

Message URLs can take any of the following syntactic forms:

message:%3cmessage_id%3e 
message://%3cmessage_id%3e 
message:<message_id> 
message://<message_id>

Both Liyanage and Gruber provide applescripts for retrieving the message id of a given email saving the message URL to the pasteboard. Gruber’s applescript is as follows:

tell application "Mail"
    set _sel to get selection
    set _links to {}
    repeat with _msg in _sel
        set _messageURL to "message://%3c" & _msg's message id & "%3e"
        set end of _links to _messageURL
    end repeat
    set AppleScript's text item delimiters to return
    set the clipboard to (_links as string)
end tell

When saved in

~/Library/Scripts/Applications/Mail/

it will appear in the script menu when Mail.app is in focus. Just select the target mail and run the script and the mail URL will be in your pasteboard ready to paste into your textfile. And if you are a keyboard fanatic who eschews the mouse wherever possible, you can use Quicksilver to run the applescript. If your text file is in markdown format, simply enclose the message URL in angle brackets.

Having the ability to link to pertinent emails really increases the usefulness of plain text notes. More so if your text editor will launch the URL for you. In TextMate, simply move the cursor over the URL and hit ⌅. Another small step in harnessing the power of plain text.

Not Weapons of Mass Destruction, nor even Word and the North Korean Missile Crisis, but Wysiwym MarkDown editor.

As discussed in a previous post Mardown is an edge case of markup. A marked-up document contains:

• text
• information about that text

A markup language determines:

1. what markup is allowed
2. what markup is required
3. how the markup is explicitly distinguished from the text
4. what the markup means

The problem, of course, is with the third requirement. So much of Markdown is implicitly determined that it fails to determine how the markup is explicitly distinguished from the text. The very name is an ironic tribute to this feature—what’s the opposite of markup? Markdown!

Nevertheless, this “plain text formatting syntax”, though not strictly speaking a markup language, can serve as a gentle introduction to markup languages for the uninitiated. It can so serve since the goal of Markdown was to be human readable and hence to be immediately familiar and accessible:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

WMD threatens to blur the boundry even further. Just as there is a distinction between information about the text being implicitly and explicitly determined, there is a distinction between visually editing this information, structurally editing this information with explicit markup. Information about the text can be visually edited, say, by bolding headers in a rich text editor. A visual element of the text, the boldface, carries implicit information about that text—that headers are in boldface. Visually editing is introducing implicit information about the text by editing the visual elements of that text. This could rather be represented by explicit markup, in which case one would be structurally editing the text. Editing your text with Markdown, while not explicit markup, is an edge case of structural editing. WMD streatches this further by offering a Wysiwym (What You See Is What You Mean) editor that produces either Markdown or HTML.

Intrigued by markup, but too shy to dip your toe? WMD may be for you.

Once upon a time, authors would send their manuscripts to their publisher where a copy editor would mark up the manuscript with instructions for the typesetter. (The origin, by the way, of the modern conception of a markup language such as HTML, LaTeX, or Markdown—if, indeed, it is one). This was only feasible if the submitted manuscript was double spaced, thus allowing adequate space for the instructions for the typesetter. This was before electronic submissions of manuscripts and before computer typesetting.

Some conventions persist beyond their utility, and the dead continue to walk the earth.

Academics, at least, are familiar with this species of the undead. Journals regularly require that paper submissions be double spaced. Just to be clear, these are submissions for consideration for publication that are sent to internal or external referees. The referees read the submission and pass on their comments to the editor who renders a judgment as to whether the submission is publishable in such an estimable journal. Referees do not write their comments on the manuscript the way copy editors used to mark up manuscripts—so why the required double spacing?

Not only does this practice lack utility, it has positive disutility. Typesetting is not, or at least not merely, an aesthetic concern; it has genuine cognitive import. Good typesetting allows the reader to better understand the text. Double spaced manuscripts are harder to read than single spaced texts. Since the manuscript is being read by a referee whose opinion the editor is relying upon in passing judgment, shouldn’t the submitted manuscript be as easy to read as possible?

And yet the dead continue to haunt the living. Like the practice of typing two spaces after a period, some conventions just won’t die. I have tried passive aggression (submitting single spaced manuscripts), I have tried active aggression (complaining about senseless anachronistic publishing practices), but when all else fails, you just have to pony up the double spaced manuscript.

If your manuscript is written in LaTeX, it may be unobvious how to achieve this. Fortunately, the setspace package can help. It is smart enough to double space the main body of text but not, say, the footnotes. Look within the package file, setpsace.sty, for instructions.

Submit your double spaced manuscript, if you must. But do so under protest. Life is for the living.

• The Markdown language module now supports syntax coloring.

• If you choose “Preview in BBEdit” when a Markdown source file is in front, BBEdit will run your Markdown source through the Markdown script, and so your preview reflects what the file will look like in a web browser. Like the previews of HTML source files, the Markdown preview will update as you edit the file.

• The TeX language module has been significantly enhanced, with folding support, improved section/subsection detection for the function menu, much more robust math-mode detection, and greatly enhanced LaTeX support. These changes resolve various reported bugs, as well. If you wish to place a “marker” in the function menu, you can write a comment of the following form: %: this is a mark. This comment syntax matches that used by TeXShop. The new TeX module also includes some support for ConTeXt, in the form of recognition and generation of fold ranges for \startXXX…\stopXXX environments, and special-case support for the “mode” environment (we ignore the contents of the mode environment, because it often contains out-of-order environment start/stop commands which can confuse the parser).

I would have loved native Markdown support when I was using BBEdit. This is one feature that initially attracted me to TextMate. The native Markdown and improved TeX support has also been implemented in BBEdit’s free cousin, TextWrangler.

For those who don’t know, Instiki is a wiki clone based on Ruby on Rails. Very easy to install and use. One virtue of Instiki is that it has the option of using Markdown, a lightweight markup language. (Or is it?). It can be used locally and is a handy way to organize notes.

Smartypants is a companion project to Markdown. It translates ASCII punctuation characters into ‘smart’ typographic punctuation. (After all, you want to be typographically correct, don’t you?)

The first problem is that the Instiki.org site seems no longer to exist. I was worried that Instiki was no more. Fortunately, after some searching, I found that Instiki can be downloaded here. There are a number of download options. The easiest for OS X users is instiki-0.10.2.dmg. Mount the dmg and drag Instiki.app to your Applications folder and your done.

You don’t need Ruby or Rails installed to run Instiki.app, all these files are contained locally. But that means you need to access the contents of Instiki.app to make Dr. Drang’s modifications. The file bluecloth_tweaked.rb can be found in the following directory:

/Applications/Instiki.app/Contents/Resources/rb_src/lib

Open that file in your favorite text editor and add

require 'rubypants'

near the top of the file with the other require lines. Towards the bottom of the to_html method add either:

text = RubyPants.new( text, 1).to_html()   

or:

text = RubyPants.new( text ).to_html()   

The former will give you em dashes with two hyphens. The latter will give you em dashes with three hyphens. I prefer the latter convention to the former and not just because it is the TeX convention. On the latter convention two hyphens gives you en dashes, whereas the former convention cannot represent these. And since hyphens, en dashes, and em dashes are progressively longer, it makes sense that they be represented by one, two, and three consecutive hypens respectively

One more modification is necessary. You need to install RubyPants in the the same directory as bluecloth_tweaked.rb. RubyPants is the Ruby implementation of SmartyPants. It can be downloaded here. Untar the file by double clicking it, and move the file rubypants.rb to:

/Applications/Instiki.app/Contents/Resources/rb_src/lib

Restart Instiki.app and now all your notes will be typographically correct. Thanks Dr. Drang!

I use Markdown everyday. All my notes are in Markdown, I write the first drafts of my papers in Markdown (then converting them to LaTeX), and, thanks to Michael Fortrin’s plugin, I am blogging in Markdown. Part of its utility is its transparency. It gets out of your way and let’s you focus on content.

Ironically, it is this very virtue that prevents it from being a markup language properly so called. In an insightful exchange on the Markdown mailing list, Allan Odgaard, the developer of TextMate, writes:

I also wonder if JG views Markdown as a markup language seeing how a lot of constructs are not exactly based on explicit markup.

John Gruber, the developer of Markdown, confirms Allan’s suspicion:

Funny, but true. I don’t really have a strong opinion about what “markup language” means, but when I was trying to decide what to call it, I thought to myself, “Well, it’s not a markup language, because the most important rules are implicit, so what would be the opposite of ‘markup’?…

Markdown, of course. Revealingly, on the Markdown website, John doesn’t describe Markdown as a markup language but as a ‘plain text formatting system’.