similar to: Tightening the rules for literal `[` and `]` chars in link ids

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

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/

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/*"

Happy new year! This is the revised revised proposal: http://maruku.rubyforge.org/proposal.md http://maruku.rubyforge.org/proposal.html http://maruku.rubyforge.org/proposal.pdf I wait for comments. -- Andrea Censi "Life is too important to be taken seriously" (Oscar Wilde) Web: http://www.dis.uniroma1.it/~censi

This is a new release for PHP Markdown, following Markdown.pl 1.0.2b7 from a few weeks ago. It fix the same bugs, and some more; it also introduce more radical backend changes. It can be downloaded here: <http://www.michelf.com/docs/projets/php-markdown-1.0.2b7.zip> and you can test it on the PHP Markdown Dingus: <http://www.michelf.com/projects/php-markdown/dingus/> This

Hi, First of all, thanks to John Gruber for the fantastic Markdown syntax and parse/render system. Also, thanks to Michel Fortin for his PHP 4 version of Markdown. Based on those two works, I have completed a **plugin-aware** PHP 5 version of Markdown. You can see it in Subversion here: * <http://solarphp.com/svn/trunk/Solar/Markdown.php> *

Hi, I have written my own implementation of markdown in Scala. I only later realized there is already one ( <http://tristanhunt.com/projects/knockoff/> ), but I put quite some work into mine and I think it is never bad to have alternatives, so I wanted to release it anyway. I want to use the same BSD License as the original markdown, but before I put it out into the wild I wanted to ask

How can we improve URL detection in Markdown? I posted a question on Stack Overflow and happened to click a URL in my post. To my surprise, it wasn't functional, and it took three different, nonintuitive manipulations before I achieved a functional URL. Stack Overflow says "not my problem", so I'm deferring to Markdown itself. Here's a

I have a doubt about the standard syntax (actually, it's the only test that maruku doesn't pass yet). Lists MUST be preceded by an empty line? So the following are only 4 paragraphs, without list items, right? ----------- Paragraph and no space: * ciao Paragraph and 1 space: * ciao Paragraph and 3 spaces: * ciao Paragraph and 4 spaces: * ciao ----------- In other words, a

It was a very useful feature for e-mail parsing and I miss it. I use PHP Markdown extra to send multipart alternative e-mail, and the short syntax [link] instead of [link][] is very clean and lean. Do you plan to implement it anymore? Or is there a tweak to get the present PHP Markdown Extra to parse [links] as [links][]? BTW I did not find mention of this in

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

Python-markdown currently replaces all straight quotes (`"`) with the html entity (`&quot;`). Someone recently complained about this in a [bug report][]. As it turns out the quote was the symptom that brought the real problem to light[^1]. In any event, the reporter pointed out that markdown.pl does not replace straight quotes with the html entity. I know John Gruber has mentioned before

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

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

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

On Feb 26, 2009, at 9:51 AM, I wrote: > I can see that really opened a can of worms here. Sorry about that. > I'll have to move up my plan to formally propose a table syntax. The > comment that started this sub-thread was a throwaway line, really. I > probably should have omitted it. And then, on Feb 26, 2009, at 3:28 PM, John Gruber wrote: > 3. A hypothetical official

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'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