Hacker News new | comments | show | ask | jobs | submit login

OK, a standard dialect of Markdown.

In the beginning was RUNOFF from MIT, which originally had about the power of Markdown. More features were added, and it became nroff, then troff, the ditrofff, and macro systems were added on top of it. It became too hard to use for casual work.

Then there was TeX, which was a saner approach to what troff did. Macro systems were added on top of it. It became too hard to use for casual work.

Then there was HTML, which started out with about the power of Markdown. More features were added. It became too hard to use for casual work.

Then there was BBcode, which started out with about the power of original HTML. It didn't gain many features, and is still widely used.

Then there was Markdown, which started out with about the power of original HTML. More features were added. Macros have been added by at least five people, but haven't quite gone mainstream yet. When Markdown gets macros, it, too, will be too hard to use for casual work.


The nice thing about Markdown that doesn't apply to those other formats is that it's designed to read naturally in plaintext. That constraint should (in theory) prevent it from transforming into something prohibitively complicated to write in.

Except for links to images. I can never freaking remember those.

Also, the silly space-at-the-end for line breaks.

> Except for links to images. I can never freaking remember those.

They work like standard Markdown links (text in square brackets, followed by link in parens), except you add a bang in front of it. The bang looks like an upside-down "i", the first letter of "image".

Edit: read too fast; _links_ to images use image instead of text in a link, so you just replace the text with text in square brackets with the syntax of Markdown image. I've never struggled too much with this one, so I don't have any useful mnemonics, sorry.

"Also, the silly space-at-the-end for line breaks."

I thought it was two spaces at end of line for a line break. Or did the one-space-at-end-of-line argument win?[1]

[1] http://meta.stackexchange.com/questions/40976/what-is-the-re...

I... never knew this.

And since my editor strips newlines on save (and no, I will not turn that feature off), I guess I can't use it.

Oh well.

It kind of scares me that I might inadvertently strip the newlines out of someone else's markdown that I'm editing, though.

If your editor supports editorconfig[1], you could set it to not strip newlines for .md files. :)

[1] http://editorconfig.org/

But I want to strip newlines from .md files.

That's why significant end of line whitespace is a terrible design feature. You can't see it. It might get deleted accidentally.

There were some systems back in the DOS/early UNIX era which had significant EOL whitespace. Spaces at the end of a line are still significant following a "\" in shell files. Some early word processors under DOS had significant whitespace at EOL, but tended to display something like a paragraph mark when it mattered.

Python had tab/space trouble at beginnings of lines, but the compiler was finally fixed so that it emits an error if tabs and spaces are mixed in a way which makes indentation visually ambiguous. That was a neat solution to the problem.

Leading tabs in makefiles were a mistake. The author of "make" once wrote that he put that in, and then, the next day, realized it was a bad idea. But he already had a user base of three users and didn't want to change it and break their code.

I thought this idea was dead and buried. Sometimes, they come back.

MD could have been fine if it were the beginning of the line. "Any indentation without a blank line above is BR"

It would make multiple repeated BRs difficult, though, but you probably shouldn't be doing that anyways.

For what it's worth, GitHub Flavored Markdown changes this to be more TeXy: any newline in text renders as a <br>, and you add an extra blank line to denote a paragraph break.

Unfortunately that means that you absolutely need to enable word wrap in your editor, people cat-ing your readme on the shell will see ugly mid-word wraps, etc. Not the end of the world or anything, but somewhat inconvenient.

That sounds like a failure of cat more than a failure of markdown. There isn't a command-line argument for cat to break long-lines at the last whitespace of the line instead of mid-word?

Err, I of course meant "strip trailing whitespace", not "strip newlines", but apparently everyone understood.

I never knew it either.

Intriguing: significant white space on the right-hand side. At least you can see the significant whitespace in Python.

I also have my editor configured to strip trailing whitespace but also to highlight it. People can be very sloppy leaving (insignificant) whitspace lying around in code.

I always forget the combination of an image with a link and alt text. [![click here)[lol.com/img.png] or something like that, the only other thing that annoys me is when people use underscoring / equals under text to make it a heading rather than #s, otherwise I find markdown a pleasure to write in.

That's why I prefer ReST. More powerful syntax out of the box with a standard extension scheme so you don't end up with the mess of all the different incompatible Markdown implementations. With the internal structure exposed as an XML format (rst2xml) it is easy to transform documentation into a wide variety of formats that docutils or Sphinx don't handle directly.

This might sound petty but it really hurts the usability of ReST for me: the link syntax is horrible. I need to look it up every single time.

A lot of that sounds good but you lost me at XML.

The XML dump exposes the parsed document structure so you aren't forced to use the usually limited output options of the native ReST or Markdown tools. Instead of generating the lackluster output from latexpdf you can transform from ReST -> Docbook -> XSL-FO -> PDF, or other targets like HTML, WordML, DocX, or ODF. Manipulating documents is what XML is really for. It gets a bad rap because it is abused so much for storing data, scripting, and other silly stuff.

I once contracted at a company where one of the salaried staff was tasked with implementing Markdown. For some reason, he actually implemented BBCode (I think with a regex he'd found online somewhere). When I tried to explain to him that BBCode and Markdown were, you know, quite different, he got angry with me and started shouting that "Markdown has no standard, so it can be anything you want!"

I left the conversation at that point because I sensed it might turn ugly (it was the afternoon, and he had a penchant for boozy lunches when his boss was out of the office).

Markdown specifically allows and recommends inline HTML for anything more complex than writing prose [1]

[1]: https://daringfireball.net/projects/markdown/syntax (see "Inline HTML")

About 0.23% of the markdown implementations everywhere accept raw HTML.

Well, sort of. HN doesn't seem to accept any HTML.

HN's formatting is not Markdown ;)

That's a feature, not a bug.

That's basically a sample size of n=5 from which you inferred that "has macros" and "is popular" are causally linked, which should get you expelled from every statistics department in the world ;)

My guess is that various syntaxes for doing basically the same thing fade in and out of popularity randomly and for the most part independent of their feature set, just as different ways of covering the body with cloth fade in and out of popularity. Last year's collection isn't unpopular because it became to hard to use, people want new stuff and they don't want to be associated with old stuff.

No, no, I don't claim that having macros is required for popularity. I claim only that the growth pattern of "simple" markup languages is to add features which make them no longer simple. At that point, new simpler markup languages appear, and the cycle repeats.

Texinfo has actually not been so bad to use, though ugly as sin. Scribble / Skribilo (racket & guile) are both excellent, but have some sharp edges. At least for HTML I've found that using a basic subset still hasn't broken.

I use org-mode pretty exclusively, but it has the opposite problem of what you mention - it requires macros in your editor (maybe a set of Editor MACroS if you will..). This makes in unusable for anyone outside the emacs lifestyle.

Markdown's issues are probably more specifically all of the edge-cases that differ from implementation to implementation. Lack of a rigid specification and near-abandonment by its author didn't help.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact