Markdown

Via yesterday's Vimcasts episode, "Converting markdown to structured HTML with a macro", check out this most-excellent Vim plugin:

Surround.vim: Delete/change/add parentheses/quotes/XML-tags/much more with ease

Surround.vim is all about "surroundings": parentheses, brackets, quotes, XML tags, and more. The plugin provides mappings to easily delete, change and add such surroundings in pairs. While it works under Vim 6, much of the functionality requires Vim 7.

Anybody editing HTML or other markup can definitely use this.

From Fletcher Penny: "Using MultiMarkdown with Scrivener"

This document assumes a basic familiarity with Scrivener, and with MultiMarkdown. It is designed to help you combine the two programs into a system to help you with the writing process, as well as the printing and publishing process.

It will guide you through the process of setting up a document that will be compatible with exporting to MultiMarkdown.

I've been taking a look at Scrivener again of late -- I waver back and forth about using it for my next book, but I'm leaning toward it at the moment.

(In case you don't know, Fletcher is the one who expanded on John Gruber's Markdown by creating the spiffy MultiMarkdown. Thanks Fletcher!)

There's a known issue with the atom.module for Drupal, which creates an Atom syndication feed to accompanying the built-in RSS feed -- the issue is that if you're also using the Markdown or Textile modules, atom.module doesn't convert the markup to proper HTML, instead showing the Markdown or Textile as is. Like I said, this is a known issue.

After a bit of investigation, I've come up with a temporary solution to the problem, at least for Markdown format. (I don't have Textile installed, so someone else will have to confirm; given the nature of the fix, I imagine it would work.)

If you check out the raw XML atom.module makes, it is creating a proper Atom file with "summary" and "content" fields. The module fills these in with the contents of the Drupal "teaser" and "body" fields respectively for each node. So far so good.

Strangely, the "teaser" field is getting formatted correctly -- in other words, the Markdown markup is being converted to regular HTML, as it should be (and as it is on the regular webpage). But the "body" atom.module is using for the Atom "content" content in is the raw Markdown, sans conversion.

Spending a bit of time familiarizing myself with the system, I've not tracked down the exact problem (though I suspect it might be an issue with the node_invoke_nodeapi usage here), but my temporary fix is to simply replace the line (line 179 in my copy of atom.module) that reads

$output .= check_markup($item->body);

with this:

$output .= check_markup($item->teaser);

All this does is use the same command as on line 173 just above, which calls the properly formatted teaser.

This is not a permanent solution by any means, and is also at the whims of whether or not you use teasers and/or excerpts, but it takes care of things for me until the real fix is in.

UPDATE

After some more experimentation, I've discovered the following:

1. atom.module apparently uses the default Input Format to display the body version of the story.
2. If that Input Format is not Markdown-capable, the story will not display properly.
3. If it is Markdown-capable, but certain HTML tags are forbidden, it will not display those.

Another temporary solution

Although this temporary solution isn't for everybody, if you allow Markdown in your default Input Format, and include appropriate HTML formatting+filtering, you will take care of the problem for now.

I have been leaning toward using Textile in the new version of the site and in general writing. As you can read in the Markup article, the initial lean was inspired by Textile's method of indicating emphasis: _emphasis_ and *strong emphasis* versus Markdown's *emphasis* and **strong emphasis**. The former seemed more natural at the time.

While casting about for Textile tools, it seems as if -- at least on the Python side of things -- development hasn't been particularly rampant lately. That combined with Merlin's recent endorsing of Markdown prompted me to revisit John Gruber's markup effort.

I first read up on some of John's methodology and liked his email "foundation":

In fact, I love writing email. Email is my favorite writing medium. I've sent over 16,000 emails in the last five years. The conventions of plain text email allow me to express myself clearly and precisely, without ever getting in my way.

Then I re-read this post of his, answering a query about the underscore/asterisk issue: asterisks as bold or italic?. This bit struck a chord with me:

...if you stop thinking about "italics" and "bold", and think instead of "emphasis" and "strong emphasis", I think it"s very fair to say that this and this both imply normal emphasis.

Fair enough. The rest of the syntax seems good, as well (though I do think I prefer Textile's header handling).

There's a bundled Perl-based conversion engine that I could use on the CLI, something I've not been able to track down for Textile. And there's the 3rd-party PHP Markdown.

Markdown is also supported in various blogging platforms, not to mention Drupal, VoodooPad, TextMate, etc.

I'm getting spoiled -- all my favorite programs are getting Markdown support thanks to some cool developers. Latest I've come across is the OmniOutliner Markdown Plugin by Fletcher Penney, which adds that markup scheme as an export option.

PlasticBoy has a page detailing a combination made in heaven: Markdown Vim Mode. :) "This is a Vim syntax file for the Markdown text-to-HTML conversion tool."

Now here's a cool thought...combining the "RSS Feeds in Email" idea from Newspipe with posting to a weblog via your email client. Suddenly you have a communication hub. Wanna blog a story you find in a favorite feed? Forward it to your own blog with email.

Then combine that with Markdown and its "email as the medium", and things begin to look very, very fun. :)