Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parsing and highlighting of fenced blocks #2994

Closed
1 task done
pjeby opened this issue Nov 27, 2017 · 3 comments
Closed
1 task done

Parsing and highlighting of fenced blocks #2994

pjeby opened this issue Nov 27, 2017 · 3 comments
Labels
type/enhancement An improvement of existing functionality
Milestone

Comments

@pjeby
Copy link
Contributor

pjeby commented Nov 27, 2017

Description

There are two problems visible in this page's rendering on try.gitea.io:

  • First, gitea's markdown processor is not CommonMark compliant for parsing fenced code blocks. (Search for the line rendered as ```shell mdsh -- this syntax is CommonMark compliant and renders correctly on Github.)

  • Second, even if the fence line is changed to something blackfriday can handle (i.e. wrapping it in { }), gitea appears to look up the entire shell mdsh line as a language name, instead of processing only the first word, the way github does. (Github's behavior in this respect is not part of the CommonMark spec, but is a reasonable default behavior.)

Probably the parsing issue needs to be reported upstream at blackfriday, but since it may impact their API, I assume that input from the gitea side would be relevant to that issue.

@lunny lunny added type/enhancement An improvement of existing functionality status/blocked This PR cannot be merged yet, i.e. because it depends on another unmerged PR labels Nov 27, 2017
@pjeby
Copy link
Contributor Author

pjeby commented Apr 28, 2018

FYI, the upstream parsing bug has been closed as fixed, so this can be revisited now. It appears that the vendored copy of blackfriday is two years old, so updating that to a newer version would be required.

Checking the upstream commits, it appears there have only been 8 PRs and one standalone commit since the dependency was vendored in late 2016. Of those, 3 PRs literally only touch the README, and 1 is the intended fix for this issue. The other five changes are dropping a dependency, adding CJK line joining, adding smart guillement formatting, fixing an infinite loop caused by self-referential footnotes, and dropping rel="footnote" from links to footnotes. All in all, updating the dependency shouldn't have a significant impact apart from the bug fixes.

@lunny
Copy link
Member

lunny commented Apr 29, 2018

will be closed by #3857

lunny pushed a commit that referenced this issue Apr 29, 2018
@lunny lunny removed the status/blocked This PR cannot be merged yet, i.e. because it depends on another unmerged PR label Apr 29, 2018
@lunny lunny added this to the 1.5.0 milestone Apr 29, 2018
@lunny
Copy link
Member

lunny commented Apr 29, 2018

resolved by #3857

@lunny lunny closed this as completed Apr 29, 2018
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

No branches or pull requests

2 participants