It's especially interesting because this same idea is also responsible for saving Rails 3's ass from being far slower than Rails 2. Read through this discussion of how Rails 3 queries were sped up by using an AST decoupled from its final use: http://www.slideshare.net/tenderlove/zomg-why-is-this-code-s....
It allows real computer scientists to laugh at stupid webdevs reinventing the wheel. </sarcasm>
(Except no one was claiming that it was a novel idea, just that in the past, most Markdown processors just convert directly between Markdown and HTML, but now they are changing that. It's also funny that there seems to be some animosity in that post towards Ruby programmers for whatever reason. It's not like Markdown is an invention of Ruby, the reference implementation was written in Perl.)
The original upskirt markdown library, written by Natacha Porté[1], had a specific goal of separating the parsing of markdown and the generation of html. When github forked it, they apparently (according to Natacha's comments on her site) slowly added more and more logic which mingled and blurred the lines.
Now this article seems to be coming from a standpoint that separation of the two concerns is somehow novel. A bit odd to say the least. I think this is where the o.p. was deriving sarcasm.
Perhaps the real story is the separation of concerns in the ruby module wrapper, instead of at the c library level? I don't know.
Actually, this is related to a question I've thought about but never asked: if you're, say, writing a blog, why use Markdown over standard HTML? Does it give some advantage I'm not aware of?
You can write content faster if you're comfortable with the syntax. It also has the advantage of looking good unstyled and styled. The syntax tends to look like a styled plaintext email.
This. I use Markdown syntax when writing blog posts since Posterous formats Markdown just fine and it lets me view my writing (mostly) unstyled in vim, which I personally find much more comfortable than some web-based editor.
I do the same, though I guess this is more the fault of current web-based editors than of HTML itself.
I'm trying to explore some ideas of simplicity in browser-based HTML editing with Hallo (http://bergie.github.com/hallo/), but remains to be seen how well that works out. In the meanwhile there is always Markdown. And Vim.
It's striking to me that markdown has become so popular, when wysiwyg HTML editors have been around for a long time, and are supposed to be easier to use (I would expect them to be).
Perhaps it's partly that using asterisks for emphasis makes more intuitive sense than ^I or clicking a button etc; and partly that mostly people don't use it - let alone the more complex markdown features.
It's not that the WYSIWYG editors aren't easy to use in most senses–they're not difficult at all. However, many people that use Markdown are probably geeky enough to not need some WYSIWYG editor in the first place.
For me, I'm in the terminal and MacVim for a good portion of my day hacking around; so, while I enjoy portions of the Google Docs(or whatever editor) interface, if I stop my usual coding activities to write a blog post, I'd like to stay in my natural environment of vim and terminal. This is particularly true if my blog post contains code–it feels much more natural for me to paste code samples between vim windows than it does to copy code from vim and paste it into some external editor.
(So, basically, it's not just the syntax, it's also the environment in which I get to write that syntax.)
The biggest advantage for Markdown is that it is in plain text. It looks good in plain text. This makes it incredibly portable, lets me write it in whatever text editor I have at hand (even ssh'd into another machine (though I don't do that very often, everything I write is just in dropbox)). I prefer having my writing sitting on my machine in straight forward plain text formats rather than in HTML. It is so much easier to deal with this way, and it is a one step process to convert it to HTML when I want to post it online. Plus, if I want to convert it to some other format, it would be trivial to do so.
Ah. Interesting. I use macros in Textmate and Typinator to accomplish more or less the same thing; for example, command-shift-v will enter "<a href=command-v">, with command-v being paste, and command-i will yield italics, and so forth. Still, having something universal, like Markdown, sounds attractive.
Markdown is for publishing, whereas Haml is for designers/developers. The point of Markdown is that non-technical users can use it, and it generally looks good and self-explanatory even unrendered.
This. I find markdown and all its bastards insufficient and their syntax hard to remember. Sometimes you can use _ other times it's * and none of them are more intuitive that <em> or <bold>.
I've always wished _ meant "underline" not <em>. Of course the HTML standard only defines <em> and <strong>, but _ could create output like <em class="underline"> or <em style="text-decoration: underline">.
Yes, the good old <u>, <b> and <i> seem to be going out of fashion. Understandable in the context of web development, but so handy for a short piece of text like a blog post or comment.
I still find myself using /emphasis/ in places, despite nothing I can think of actually supporting it. I can't remember where it originated, possibly usenet.
Actually, markdown is great for this kind of stuff - it's when you start getting into links, inserting attributes, etc. that I'd rather just write HTML.
HTML may be easier for you (it certainly is for me), but that's because you are a programmer. You must keep in mind that Markdown targets a very wide audience: you cannot expect your average Reddit user to write emphasis tags every time he wants to say something sarcastic in a comment, and trust me, that's pretty often.
Likewise, you cannot expect the average Joe to remember the syntax of an HTML link tag when writing a comment in your website, but you do need (at least we do) to make sure that the links in your website have certain attributes (rel, target, etc): Hence, customizable Markdown.
For me the problem if i write html is that i write it different all the time. In one place i might use <b> while i the next time use <strong> or maybe even go as far as <p style="font-weight:bold;">.
Forgot to change paragraph with a </p><p>? Just add a <br /> instead!
With markdown there is only ONE way to do things right and there's not many thing you can do (wrong) actually. With html it's too easy to go overboard and either mess things up or start being creative with individual styles all over.
Is there any consensus on an improved/extended Markdown?
Between MultiMarkdown, Github Flavored Markdown, Stack Exchange's additions, this new "elegant" markdown and others there seems to be bit of fragmentation in this idea of a simple markup.
No, there isn't really a consensus. FWIW, this is not a "new elegant Markdown", this is a 100% standards compilant Markdown library, with optional support for some extensions that we found useful. The syntax for these extensions comes, basically, from the Markdown mailing list and PHP-Markdown Extra.
It's used on http://uponahill.com to extract Flickr urls so I can query the Flickr API and get complete metadata about each photo. My gf, who does most of the writing/photography on the site, has found writing in Markdown and copy/pasting Flickr urls a pretty frictionless experience compared to the Wordpress CMS.
Speaking of Markdown and Github, has anyone figured out a way to preview locally - with accuracy - how README.mdown files will look on the project page? Would Redcarpet 2 help solve this problem?
70 comments
[ 4.5 ms ] story [ 121 ms ] thread(Except no one was claiming that it was a novel idea, just that in the past, most Markdown processors just convert directly between Markdown and HTML, but now they are changing that. It's also funny that there seems to be some animosity in that post towards Ruby programmers for whatever reason. It's not like Markdown is an invention of Ruby, the reference implementation was written in Perl.)
Now this article seems to be coming from a standpoint that separation of the two concerns is somehow novel. A bit odd to say the least. I think this is where the o.p. was deriving sarcasm.
Perhaps the real story is the separation of concerns in the ruby module wrapper, instead of at the c library level? I don't know.
[1]: http://fossil.instinctive.eu/libupskirt/index
I'm trying to explore some ideas of simplicity in browser-based HTML editing with Hallo (http://bergie.github.com/hallo/), but remains to be seen how well that works out. In the meanwhile there is always Markdown. And Vim.
Perhaps it's partly that using asterisks for emphasis makes more intuitive sense than ^I or clicking a button etc; and partly that mostly people don't use it - let alone the more complex markdown features.
https://github.com/bergie/hallo/issues/11
This way you start writing _something, and it becomes something
For me, I'm in the terminal and MacVim for a good portion of my day hacking around; so, while I enjoy portions of the Google Docs(or whatever editor) interface, if I stop my usual coding activities to write a blog post, I'd like to stay in my natural environment of vim and terminal. This is particularly true if my blog post contains code–it feels much more natural for me to paste code samples between vim windows than it does to copy code from vim and paste it into some external editor.
(So, basically, it's not just the syntax, it's also the environment in which I get to write that syntax.)
In fact, I wouldn't mind if javadoc supported it too.
(Sorry)
Even more reason for it to be supported in Markdown :)
Likewise, you cannot expect the average Joe to remember the syntax of an HTML link tag when writing a comment in your website, but you do need (at least we do) to make sure that the links in your website have certain attributes (rel, target, etc): Hence, customizable Markdown.
Forgot to change paragraph with a </p><p>? Just add a <br /> instead!
With markdown there is only ONE way to do things right and there's not many thing you can do (wrong) actually. With html it's too easy to go overboard and either mess things up or start being creative with individual styles all over.
Eh, what's that now? Isn't Markdown implementation-defined? I wasn't aware there was a spec, I thought it was just some notes on a dude's blog.
Pandoc is written in haskell but there's c bindings to it https://github.com/toyvo/libpandoc so you can use it from anywhere.
Check it out: https://github.com/tmm1/pygments.rb
https://github.com/joehewitt/markdom
It's used on http://uponahill.com to extract Flickr urls so I can query the Flickr API and get complete metadata about each photo. My gf, who does most of the writing/photography on the site, has found writing in Markdown and copy/pasting Flickr urls a pretty frictionless experience compared to the Wordpress CMS.
[1]: https://github.com/evilstreak/markdown-js
I'm going to take another look at it soon.