Issue and pull request references unexpectedly interpreted as headings

[pluehne]

• Gitea version (or commit ref): 1.3.1 and b6d2243 (try.gitea.io)
• Git version: 2.15.1
• Operating system: Arch Linux
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes: https://try.gitea.io/test/2017-12-14-debug-leading-hash/issues/1#issuecomment-1620
  • No
  • Not relevant
• Log gist: not relevant

Description

When writing issue or pull request comments, lines that start with a # character are unconditionally rendered as headings. This takes precedence over interpreting the # character as the beginning of an issue or pull request reference such as #3189. This was unexpected for me, because I sometimes start sentences with an issue or pull request ID.

Consider the following comment in Markdown:

This is a reference to #1.

#1 addressed this issue first.

#100000 doesn’t exist yet.

# Leading hash used with space = heading

#Leading hash without space = normal text

This is rendered by Gitea as follows:

---

---

Note that the same text is treated very differently by GitHub:

---

---

The reason for the difference seems to be that GitHub only considers lines starting with # as headings if the # is separated from the text by at least one whitespace.

I guess that GitHub shouldn’t serve as the only source of truth in such decisions. However, quoting CommonMark as a more objective source:

4.2 ATX headings

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

… Note that many implementations currently do not require the space. However, the space was required by the original ATX implementation, and it helps prevent things like the following from being parsed as headings:

Example 34

#5 bolt

#hashtag

I think that this specification detail is reasonable, considering the examples mentioned above in the CommonMark document as well as the use of # for referencing issues and pull requests. For this reason, I suggest adjusting Gitea’s Markdown implementation for consistency with CommonMark.

[pluehne]

I just read in issue #3231 that Gitea is using Blackfriday as a Markdown processor. Is this issue something I should file in the Blackfriday repository instead?

I still think it would be best to follow the Commonmark specification, but I’m not sure whether Blackfriday adheres to this standard.

[lafriks]

Not really as issue/PR linkng is happening in gitea side

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[pluehne]

Just to keep this issue from being discarded by the stale bot, I can still reproduce this behavior on Gitea 1.7.3. I think it would be good to have Gitea’s interpretation of Markdown match GitHub’s. I’d be willing to work on this, but I’m pretty busy with other things at the moment.

@lafriks: Can you elaborate what you mean by “PR linking is happening in Gitea side”? That’s what I would expect, can’t it be changed?

[lafriks]

Just that changes need to be done in Gitea code not in blackfriday library

[samurous]

When using lists of issues, they are also sometimes interpreted as headings but not always as demonstrated in this example: https://try.gitea.io/samurous/markdown_test/src/branch/master/README.md

Here

* #1 My 1st Issue.
* #2 My 2nd Issue.


* A new List.
* With another point.

Is rendered to:

It seems only the last point will be rendered as a heading.

[guillep2k]

Issue still present in master pre 1.11 (7b75603) with blackfriday/v2:

[guillep2k]

This can be closed as it was fixed when we migrated out of blackfriday.

https://try.gitea.io/guillep2k/charset-problem/issues/2#issuecomment-25596

[pluehne]

@guillep2k: How cool, thanks for pointing this out!