Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Elegant Markdown for a more civilized age (vmarti.net)
97 points by tanoku on Aug 3, 2011 | hide | past | favorite | 63 comments


Wow, what a crazy idea. Decoupling parsing from output generation. What will those crazy Ruby kids think of next?


I wonder how many people are seeing the sarcasm, and how many think you are serious. =)


What's the markdown tag for sarcasm again?


nine whitespace characters at the end of a newline


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


47 comments in this thread and this is the top comment. Could someone explain what value it adds to the conversation? I'm completely missing it.


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.

[1]: http://fossil.instinctive.eu/libupskirt/index


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.)


Also, fore a more robust and extensible Markdown parser, see the perl's Markdent: http://search.cpan.org/dist/Markdent/


I recently wrote something just like this for Node.js:

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.


Darn...I was hoping it was pure javascript so I could run it client-side. Nicely done, though!


You could try markdownjs[1].

[1]: https://github.com/evilstreak/markdown-js


I already know about that and I like it. I wanted to see a different take on it, though!

I'm going to take another look at it soon.


At a certain point, isn't it easier to just write the HTML?


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.


I think it would make a lot of sense for WYSIWYG editors to support Markdown-like microsyntax for simple formatting:

https://github.com/bergie/hallo/issues/11

This way you start writing _something, and it becomes something


Agreed. It gracefully degrades into something readable if parsing fails, which is not applicable to HTML.


Particularly useful for HTML e-mail - write once and it'll look great in both the plaintext version and the HTML one.


It's a writer's tool, rather than a coder's tool. Markdown text is getting on for half as long as equivalent HTML.

        # Subheading
        
        ## Main heading
        
        Plain paragraph.
        
        - bullet
        - bullet
        - bullet
        
        Paragraph.
87 characters in Markdown. 147 in HTML. If I write in HTML, I get distracted from the words by the HTML markup...


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.


For blog posts, README's for github and stuff like that the source in markdown kind of looks better than the equivalent HTML tag soup.

In fact, I wouldn't mind if javadoc supported it too.



Imagine having to write a few lists or tables in HTML. I think writing Markdown in those cases is a bit faster and much more pleasant.


Assuming http://www.leancrew.com/all-this/2008/08/tables-for-markdown... is accurate, HTML tables look much more readable to me. /shrug


Since it's allowed in HTML to not close <li> tags, lists are pretty readable and easy to write:

    <ul>
      <li>Item 1
      <li>Item 2
      <li>Item 3
    </ul>


Haml is also great for writing <table>'s.


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.


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.


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


Actually, it's <strong> and not <bold> ;)


Can't believe I made that mistake ;)


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.


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">.


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.


<u>


Oh hey, look at that, they un-deprecated <u> in HTML5: http://dev.w3.org/html5/markup/u.html#u

Even more reason for it to be supported in Markdown :)


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.


It also encourages putting <em> and <strong> everywhere instead of choosing the proper tag between <em>, <strong>, <b>, <i>, <u>, <cite>, <q>.


<strong>.

(Sorry)


Then you're restricted to HTML. You can parse Markdown and emit LaTeX, HTML, OPML—anything structured.


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.


> this is a 100% standards compilant Markdown library

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.


I think the "Markdown standard" could be considered to be Gruber's official docs: http://daringfireball.net/projects/markdown/syntax


Yes, it is just some notes on a dude's blog. Well put.


I don't know what he meant by that either.


Is Maruku's metadata syntax supported? http://maruku.rubyforge.org/proposal.html


Just curious if there was a reason why this is not on the official Github blog?


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?


Nice. I like the idea with the renderers. I'm going to this idea a try too for my Python binding.


Redcarpet is great, but for code highlighting you can use pygments.rb, which has an embedded python in it and is therefore faster than albino.

Check it out: https://github.com/tmm1/pygments.rb


Am I the only one that found the font on that page distracting?


[deleted]


Perhaps because there's multiple 'markdown-ruby's and they all want to be distributed as RubyGems. More importantly, I rather like many of the names!


excellent. Maybe now there well be an elegant way to go from .markdown to .docx


Pandoc does that already http://johnmacfarlane.net/pandoc/

Pandoc is written in haskell but there's c bindings to it https://github.com/toyvo/libpandoc so you can use it from anywhere.


docx, why?! You're being sarcastic, right? right?!


Someone shall port this to Python (and possibly PHP).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: