One of the first comments when not-so-technical people use Markdown is that they expect a Newline to create a newline (without needing 2 spaces). With the stmd.js it's possible to set renderer.softbreak = '<br/>'; to do exactly that (assuming var renderer = new stmd.HtmlRenderer()), but it's also sometimes desirable to create an actual new paragraph for it.

renderer.softbreak = '</p><p>'; works, but that closing tag smells since it requires ambient knowledge about the fact that an opening <p> is there.

I don't think there is a good way to allow the parser to handle this, since that would introduce ambiguity or options into the spec. So it should be in the renderer, but there seems no good extensibility point in it - renderInline doesn't seem to have auxiliary information about the fact that it is in an open <p> tag.

I guess it'll be a problem in any case because of potential newlines in Lists or other elements, but I wonder if someone would have an idea if there is a sane extensibility point not?

I agree we need excellent support for the very, very common convention of treating new lines as line breaks in Markdown.

It is easily the number one "switch" sites immediately flip when they use Markdown. Nothing confuses the average user more than hitting enter and not getting a new line like they expect in every other common input area on the web.

Treating newlines as line breaks is already supported easily in the JS reference implementation (I haven't looked at the C one), and the doc mentions this use case already, saying parsers may provide an option to treat softbreaks as hardbreaks.

However, this is not what is being requested here. The issue is talking about treating softbreaks as paragraphs. IMO, this creates all sort of issues. What happens when someone adds a hardbreak in the doc if you decide to treat newlines as paragraphs ? Does it get a hardbreak or a paragraph change in the output ?

Indeed—I'd go so far as to say that requiring the two spaces or backslash is not just unintuitive for average users, it's completely backwards.

It's a common convention to allow newlines to be escaped with a backslash, but with Markdown we're using a backslash to unescape, which seems bizarre. From what I've seen, it's the only part of Markdown that people find truly counterintuitive.

(ETA: As stof says, that's not really the topic of this request; perhaps a new thread is in order.)

Indeed, "Treat Softbreak as <br/>" trivial (stmd.js is really nicely extensible - you have to read the source though), but treat as a new paragraph introduces all sorts of edge-cases (e.g., what about List Items? Blockquotes?) - I don't believe this is something the Spec or Parser should touch. I think that it would be up to the renderer to report state down to the individual render-functions.

This might be a case where I'm basically creating my own flavor of Markdown (eeeek) simply because a specific (internal) application for a specific circle of users would benefit from it, so I was more looking if there is already a good extensibility point or if I should create a new Html Writer that makes state available to individual functions.