Markdown 1.0.1

Markdown 1.0.1 is now available. This release was primarily focused on fixing bugs and eliminating certain ambiguities and confusing edge cases in Markdown’s formatting syntax.

Release Notes

  • Changed the syntax rules for code blocks and spans. Previously, backslash escapes for special Markdown characters were processed everywhere other than within inline HTML tags. Now, the contents of code blocks and spans are no longer processed for backslash escapes. This means that code blocks and spans are now treated literally, with no special rules to worry about regarding backslashes.

    NOTE: This changes the syntax from all previous versions of Markdown. Code blocks and spans involving backslash characters will now generate different output than before.

  • Tweaked the rules for link definitions so that they must occur within three spaces of the left margin. Thus if you indent a link definition by four spaces or a tab, it will now be a code block.

    NOTE: This may affect existing Markdown content if it contains link definitions indented by 4 or more spaces. This was never officially supported, but neither was it explicitly disallowed.

  • Added >, +, and - to the list of backslash-escapable characters. These should have been done when these characters were added as unordered list item markers.

  • Trailing spaces and tabs following HTML comments and <hr/> tags are now ignored.

  • Inline links using < and > URL delimiters weren’t working:

    like [this](<>)
  • Added a bit of tolerance for trailing spaces and tabs after Markdown hr’s.

  • Fixed bug where auto-links were being processed within code spans:

    like this: `<>`
  • Sort-of fixed a bug where lines in the middle of hard-wrapped paragraphs, which lines look like the start of a list item, would accidentally trigger the creation of a list. E.g. a paragraph that looked like this:

    I recommend upgrading to version
    8. Oops, now this line is treated
    as a sub-list.

    This is fixed for top-level lists, but it can still happen for sub-lists. E.g., the following list item will not be parsed properly:

    +   I recommend upgrading to version
        8. Oops, now this line is treated
        as a sub-list.

    Given Markdown’s list-creation rules, I’m not sure this can be fixed.

  • Standalone HTML comments are now handled; previously, they’d get wrapped in a spurious <p> tag.

  • Fix for horizontal rules preceded by 2 or 3 spaces.

  • <hr> HTML tags in must occur within three spaces of left margin. (With 4 spaces or a tab, they should be code blocks, but weren’t before this fix.)

  • Capitalized “With” in “Markdown With SmartyPants” for consistency with the same string label in (This fix is specific to the MT plug-in interface.)

  • Auto-linked email address can now optionally contain a ‘mailto:’ protocol. I.e. these are equivalent:

    <mailto:[email protected]>
    <[email protected]>
  • Fixed annoying bug where nested lists would wind up with spurious (and invalid) <p> tags.

  • You can now write empty links:

    [like this]()

    and they’ll be turned into anchor tags with empty href attributes. This should have worked before, but didn’t.

  • ***this*** and ___this___ are now turned into


    Instead of


    which isn’t valid. (Thanks to Michel Fortin for the fix.)

  • Added a new substitution in _EncodeCode(): s/\$/&#036;/g; This is only for the benefit of Blosxom users, because Blosxom (sometimes?) interpolates Perl scalars in your article bodies.

  • Fixed problem for links defined with urls that include parens, e.g.:


    “Chomsky” was being erroneously treated as the URL’s title.

  • At some point during 1.0’s beta cycle, I changed every sub’s argument fetching from this idiom:

    my $text = shift;


    my $text = shift || return '';

    The idea was to keep Markdown from doing any work in a sub if the input was empty. This introduced a bug, though: if the input to any function was the single-character string “0”, it would also evaluate as false and return immediately. How silly. Now fixed.