similar to: footnote syntax

I also agree that single bracket reference-style syntax is not prudent. As Jacob suggested, it creates ambiguity for the reader (Is it an edit or a link?). It also creates a new problem of potential conflict, however rare that may be. It seems reasonable to prefix a marker colon (possibly followed by whitespace): [:ref link] or [: ref link] And perhaps the same for attributes: {:att ref} or {:

I just received a report [1] that the footnote output we use in Python-Markdown (an exact copy of PHP Markdown Extra [3]) is not valid HTML [3]. If you notice he's using HTML5. At least the footnote syntax does valid on XHTML1 or HTML4. Anyway, any suggestions on how the various footnote implementations want to move forward with this? [1]: https://github.com/waylan/Python-Markdown/issues/129

I just received a [bug report] for Python-Markdown complaining that colons are used in the ids of footnotes. For reference, we [output] the same format at PHP Markdown Extra. The general complaint is that the colon in the id attribute (`id="fnref:1"`) causes jquery to choke when referencing that id from javascript because jquery uses colons to indicate pseudo elements (as does CSS). As

Hi All. I've just started using Markdown for my blog. So far it seems quite nice, but the one issue I've run into is a lack of "native" support for footnotes. I think that Daring Fireball's footnote style makes a lot of sense, and that's what I intend to use. However, it is a bit cumbersome to implement that style from within Markdown. I notice that the PHP

> [John Fraser:] Being able to wrap Markdown text in divs and spans ... I find div and span tags quite useful. Here is an example of the syntax I'm presently using. [[ {#orchard} Contents of div here. And ~this{.plum}~ is how I do spans. ]] becomes <div id="orchard"> <p>Contents of div here. And <span class="plum">this</span> is how I do

Along with the new release of PHP Markdown 1.0.2b7 comes this new version of PHP Markdown Extra. It contains every improvements of PHP Markdown 1.0.2b7 plus some new fixes and two new features. You can download it here: <http://www.michelf.com/docs/projets/php-markdown-extra-1.1b1.zip> and you can test it on the PHP Markdown Dingus (select PHP Markdown Extra):

I'm currently attempting to write a spec for parsing Markdown Extra, and since one goal is to minimize the differences in output between implementations, I've made a tool allowing me to compare who does what for any given input. I hope this can also facilitate future discussions about the syntax. So here's Babelmark, a testbed for various Markdown implementations were you

Hi, I'm in the process of adding support for Markdown to a minimal CMS in Rails, [Railfrog][railfrog], which uses mime types to select appropriate processing. I have had a look through the archives but have not been able to see that a consensus has emerged as to what such a mime type for Markdown should look like. My reading of the RFCs suggests that it should be within the "text/*"

Hello all, I've began writing the parsing section of the spec, and I though I'd let you know about where I'm heading with all this. Basically, parsing is defined as three consecutive passes: parsing document elements, parsing block elements and parsing span elements. Each pass is going to contain a set of rules the parser should attempt to match while parsing the input. Rules

Time for an update to PHP Markdown and PHP Markdown Extra. <http://michelf.com/project/php-markdown/> This new version of PHP Markdown Extra adds support for "fenced" code blocks (which I was previously calling "flat"). Fenced code blocks overcome many limitations of Markdown's indented code blocks: they can can be put immediately following a list item, can

Markdowners, just a short heads-up to a newly released Markdown implementation: "pegdown" (http://github.com/sirthias/pegdown) implements a Java Markdown-to-HTML processor based on a PEG parser with the grammar being based on John MacFarlanes C implementation "peg-markdown". pegdown uses "parboiled" (http://www.parboiled.org) for the actual parsing work and, as

This update to PHP Markdown fix a bug that slipped in the WordPress interface with the last update. It also introduce a new "feature": you can now instruct the parser to ignore HTML tags and/or entities in the input. You can do this by instantiating yourself the parser and setting the `no_markup` or `no_entities` properties to true: $parser = new Markdown_Parser;

>>> I'm not sure the indentation feature is so useful. After all, you >>> can use the old syntax if you want indentation. What do you think? >> >> I'd prefer to keep it simple and leave out the indentation feature. I would also prefer to leave this out. >>> Perhaps an alternative would be to use ++++s instead of ~~~~s. >> Advantages: Not

Hello, What should the following input produce? Dutch has shifted Germanic g to the velar fricatives [?] and [x], but retained the spelling with <g> and thus at least a visual similarity to German; English and Frisian have shifted g to [j] before palatal vowels The Dingus says: <p>Dutch has shifted Germanic g to the velar fricatives [?] and [x], but retained the spelling

Does anyone know which version of Markdown is best for Wordpress? I see online that there are a few and was wondering which one people prefer. Also, is there any chance John Gruber will write an official Markdown plugin for Wordpress, given how popular it's becoming? -------------------------------------------------------- robdumas at gmail.com http://obnoxio.us/

I am glad to see support for footnotes working its way into other implementations of Markdown! However, I have a couple of issues. Issue # 1. There appears to be a bug in the footnote parser that causes material following the footnote to be included as part of the footnote. For example: < Example Section > ## Metadata ## First, take a look at the overall structure of the document.

I'm using Michel Fortin's MDTest cases to rewrite my html2text.php script. Just now I stumbled upon this bug (in PHP Markdown at least): # Input: Backtick: ``\``` # Output: <p>Backtick: ``&#96;``</p> # Should-Be Output: <p>Backtick: <code>`</code></p> If you (Michel) are already aware of this, just ignore me ;-) -- Milian Wolff

The following benchmarks have been obtained using the TextMate manual as the input source: <http://macromates.com/textmate/manual/source.tbz> Using PHP Markdown, parsing the 24 files separately (with the reference file appended to each of them), I get this (on an iBook G4 1.2 Ghz): Total Avg. Min. Q1. Med. Q3. Max. Parse Time (ms):

I'v encountered what seems to be a bug in PHP Markdown v1.0.1k. Given a UTF-8 with a BOM, the first line is not parsed. A brief search revealed a bug report for a similar issue in python- markdown: > I'm using the markdown.py command to generate HTML from Markdown > documentation and I've found that if a utf-8 file starts with a BOM > a paragraph is generated

So here's an interesting bug I just discovered: [Like this][d]: [here][h]. [d]: foo [h]: bar The output here should be: <a href="foo">Like this</a>: <a href="bar">here</a>. But instead the output is completely empty. I see this bug in both Markdown.pl and PHP Markdown. The problem is that all three lines are being