Headers should be a serie of '#' followed by at least one whitespace

[ArthurHoaro]

Using Parsedown 1.6.

Currently, this

 #nottitle 

will render as:

<h1>nottitle</h1>

As specified in CommonMark specification:

The opening sequence of # characters must be followed by a space or by the end of line.

Also:

At least one space is required between the # characters and the heading’s contents, unless the heading is empty. Note that many implementations currently do not require the space. However, the space was required by the original ATX implementation

Expected result, same as Github:

#nottitle

Use case: I extended Parsedown to support #hashtags in my software, and hashtags set at the beginning of a new line now generate a header.

EDIT: that's probably not the best way to do it, but I added this to my Parsedown extension to fix it:

protected function blockHeader($line)
{
    if (preg_match('/^#+ /', $line['text'])) {
        return parent::blockHeader($line);
    }
}

[erusev]

This looks like a duplicate of #265

[ArthurHoaro]

Well #265 seems to be the exact opposite (and the issue closed), but yes, that's related.
In this thread, you said that this behaviour is expected, due to existing texts. Why not, but what specification should we refer to when using Parsedown?

[erusev]

There's a long and ongoing discussion about the topic at CommonMark forums - looks like this is a rule that might change in future versions of CommonMark.

[aidantwoods]

@erusev I know that #265 happened which previously caused a fix for this issue to be reverted. Given that this occurred over three years ago, I wonder whether given the success of CommonMark in that time, it might be best to behave according to spec by default? Perhaps we could add a setter for those that really don't want to have a space there.

[NathanBaulch]

I really need proper support for lines that begin with #hashtags, per the CommonMark and GFM specs. Please consider pull request #589.

[aidantwoods]

Closing as #589 was merged.

The current plan is to add a strict mode in 1.8.0 (as suggested in #265 (comment)) to hopefully side step this dichotomy between supporting a commonly used deviation from the spec, and honouring the spec.

Currently this is the only case that strict mode controls, but this opens up the possibility of releasing very breaking (but compliant) changes in the future into strict mode (similar to this case) since the intent of the setter is to be compliant.

I think it is wise to be as compliant as possible even when strict mode is off, but if there are changes where compliance generates major unforeseen breakage in existing texts (like #265) then it is nice to be able to limit that change to those that want strict compliance.