Hacker News Reader

Comment by Pxtl | Hacker News Reader

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.

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?

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.

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.

Reply on news.ycombinator.com