Hacker News Reader

Comment by Aardwolf | Hacker News Reader

For me it sucks because it ignores single newlines

Almost any place where I have to type markdown feels like it's plain text (typing a readme in an actual plain text editor, a git comment in vim, a plain text box like this one here in hacker news and reddit that also ignores newlines, ...), and plain text is supposed to listen to your newlines

But markdown will happily turn your two things you put on separaate lines into a single line, ruin source code or ascii art without adding special formatting, etc...

It should wrap long lines, but should listen to explicit newlines. The simplest text editor can, and does, do that.

View on HN

I'm old school. I like my source files to be at most 80 characters wide. So for plain text, yes a markup language should reformat paragraphs.

Pre-formatted text is different. But that usually requires a separate context to make sure that all space stays in place, not just newlines.

The problem is that in most cases where I have to use markdown, it's not a source file. E.g. if in a git comment I use a single newline to separate some points, it's often a surprise to then find them concatenated on a single line.

Like this very hacker news comment box here. I know it's not really markdown, but it also ignores single newlines. Why?

Markdown is not really presenting itself as being source code, or at least it's not being used as such in many places. If you want source code, why not use something more powerful than something that tries to look like plain text, except it alters your whitespace?

Also, in programming source code it's natural to try to keep it within 80 characters. But markdown is for writing natural language, isn't it a nightmare then to keep all lines 80 characters if you edit previous sentences or insert a word somewhere?

Markdown has a syntax for bullet lists, why not use that?

The nice thing about standards is that there are so many to chose from. It would be nice if there were a single light weight markup language.

In many contexts you need something where text can be reflowed. Hacker News is a good example. It would be bad if all comments with long lines would show up with scroll bars.

So if the output is going to be reformatted anyhow, then it is better to use a light weight markup language that provides a quick way to provide the most common rendering hints.

And at that point your input text is source.

> It would be bad if all comments with long lines would show up with scroll bars.

No it woulnd't, more newlines (by not ignoring single newlines) would make lines shorter on average, not longer.

It should of course auto wrap long lines (and plain text does), horizontal scrollbars suck.

So markdown only makes you choose between ignoring your single newlines or preformatted text with horizontal scrollbars but cannot combine best of both worlds? That makes it even worse.

> The problem is that in most cases where I have to use markdown, it's not a source file. E.g. if in a git comment I use a single newline to separate some points, it's often a surprise to then find them concatenated on a single line.

Git commit messages (I assume that's what you mean by comment) are conventionally fill-paragraph'd with the traditional 72/80 limit, so I would expect this reformatting to occur. Markdown has proper bulleted list supports, use that. Or paragraphs. It also supports explicit linebreaks (two trailing spaces) but that's usually hard to read.

> Like this very hacker news comment box here. I know it's not really markdown, but it also ignores single newlines. Why?

Well in no small part because it blows chunks.

> But markdown is for writing natural language, isn't it a nightmare then to keep all lines 80 characters if you edit previous sentences or insert a word somewhere?

1. markdown (and most other lightweight markups) grew from email conventions and conventionally formatted text files (check out the text RFCs)

2. in emacs, re-filling a paragraph is an M-q away

> But markdown is for writing natural language, isn't it a nightmare then to keep all lines 80 characters if you edit previous sentences or insert a word somewhere?

No, press M-q, done. But it is nightmare, if the lines are long, or additionally cut in the middle of the word.

Yes - to add to that, Markdown was based on the ways emails were traditionally formatted. Since breaks at 72-80 characters in that context don't reflect a new paragraph, Markdown helpfully reflows them when converting to a variable line width context. This is actually one of my favorite features of Markdown.

So much so that I wish email clients would treat incoming text emails as Markdown, reflowing and formatting them as needed.

I actually set max-width on Hacker News to 80 characters, so I get this (much easier to read) behavior everywhere. :-)

I really like that I can have the source file broken up over several lines but that it still defines a semantic "paragraph" that is rendered properly when convert to HTML or Latex.

If it respected single newlines, then I'd feel compelled to avoid newlines, but I'm trained too strongly on respecting column-formatted text files (though I don't stick religiously to the 72 or 80 char limit), so this would be a problem for me.

yes, it can be unintuitive, but single newline ignorance has its advantages too, for example one can make semantic line breaks[1] for easier diffability.

[1]: https://sembr.org/

It actually comes from plaintext emails. If you read emails like that a lot in a terminal you might agree a blank line between paragraphs will ease the reading.

Markdown is designed around the assumption that you are writing text for humans to read. Thus for a paragraph break, leave a blank line.

Reply on news.ycombinator.com