Issue and pull request references unexpectedly interpreted as headings #1361

New Issue

GiteaMirror · 2025-11-02T03:57:50-06:00

GiteaMirror commented

2025-11-02 03:57:50 -06:00

Originally created by @pluehne on GitHub (Dec 13, 2017).

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.

Originally created by @pluehne on GitHub (Dec 13, 2017). - 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]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] 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: -------- ![screenshot from 2017-12-14 00-44-04](https://user-images.githubusercontent.com/3244280/33968393-f18c88cc-e067-11e7-89e8-2ed090a1538e.png) -------- Note that the same text is treated very differently by GitHub: -------- ![screenshot from 2017-12-14 00-46-23](https://user-images.githubusercontent.com/3244280/33968450-3c95f57e-e068-11e7-82f4-5cfdea696754.png) -------- 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](http://spec.commonmark.org/0.27/#atx-headings): > ### 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.

GiteaMirror added the topic/ui issue/confirmed type/enhancement labels 2025-11-02 03:57:50 -06:00

GiteaMirror closed this issue

2025-11-02 03:57:51 -06:00

GiteaMirror commented

2025-11-02 03:57:52 -06:00

@pluehne commented on GitHub (Dec 19, 2017):

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.

@pluehne commented on GitHub (Dec 19, 2017): I just read in issue #3231 that Gitea is using [Blackfriday](https://github.com/russross/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](http://commonmark.org/), but I’m not sure whether Blackfriday adheres to this standard.

GiteaMirror commented

2025-11-02 03:57:52 -06:00

@lafriks commented on GitHub (Dec 19, 2017):

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

@lafriks commented on GitHub (Dec 19, 2017): Not really as issue/PR linkng is happening in gitea side

GiteaMirror commented

2025-11-02 03:57:52 -06:00

@stale[bot] commented on GitHub (Feb 10, 2019):

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.

@stale[bot] commented on GitHub (Feb 10, 2019): 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.

GiteaMirror commented

2025-11-02 03:57:52 -06:00

@pluehne commented on GitHub (Feb 28, 2019):

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?

@pluehne commented on GitHub (Feb 28, 2019): 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?

GiteaMirror commented

2025-11-02 03:57:53 -06:00

@lafriks commented on GitHub (Mar 10, 2019):

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

@lafriks commented on GitHub (Mar 10, 2019): Just that changes need to be done in Gitea code not in blackfriday library

GiteaMirror commented

2025-11-02 03:57:53 -06:00

@samurous commented on GitHub (Nov 13, 2019):

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.

@samurous commented on GitHub (Nov 13, 2019): 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 ```markdown * #1 My 1st Issue. * #2 My 2nd Issue. * A new List. * With another point. ``` Is rendered to: ![grafik](https://user-images.githubusercontent.com/28673531/68766866-f86f0680-061f-11ea-9d0a-fe2b51516435.png) It seems only the last point will be rendered as a heading.

GiteaMirror commented

2025-11-02 03:57:54 -06:00

@guillep2k commented on GitHub (Nov 13, 2019):

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

@guillep2k commented on GitHub (Nov 13, 2019): Issue still present in `master` pre 1.11 (7b75603ffed7e1bcdde7819e35d86d54d3bfc0ae) with `blackfriday/v2`: ![image](https://user-images.githubusercontent.com/18600385/68805192-0f265500-0642-11ea-92bc-6c0f3792fd33.png)

GiteaMirror commented

2025-11-02 03:57:54 -06:00

@guillep2k commented on GitHub (Jan 7, 2020):

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

@guillep2k commented on GitHub (Jan 7, 2020): 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

GiteaMirror commented

2025-11-02 03:57:54 -06:00

@pluehne commented on GitHub (Jan 8, 2020):

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

@pluehne commented on GitHub (Jan 8, 2020): @guillep2k: How cool, thanks for pointing this out!

GiteaMirror referenced this issue

2025-11-02 11:56:41 -06:00

[PR #1361] [MERGED] Clean-up PostgreSQL Tests #15877

Sign in to join this conversation.