int main() {
}
I'll only add notice to remember about using rel="nofollow" in case of any links happening in tickets or comments.
Autolinking stuff like ~owner/project or #ticketid will be nice too, but especially the latter may often lead to false positives, when there is some #number in text, yet it isn't reference to any ticket. So it will be good to introduce own referencing system and document it.
For instance:
ticket:#id- ticket in same tracker~owner/tracker/#id- ticket #id in other tracker- 'git:~owner/project' - git repository
'git:~owner/project' was supposed to be
git:~owner/project- somehow I didn't use backticks here.
Added rel="noopener nofollow" to links and added auto-linkification. Still want to get checklists implemented and automatically handle ~owner/project et al.
Linkification is done.
\```-style code blocks were requested here:
Making a note here as discussed briefly on IRC to consider switching to commonmark as it elevates markdown to the more capable markup formats like rst and asciidoc making it suitable for documentation rather than blog posts.
Commonmark is ultimately based on pandoc's markdown but has its own proper spec and reference tooling written in C. There are also other implementations listed here: https://github.com/commonmark/CommonMark/wiki/list-of-commonmark-implementations
An additional negative point to make about commonmark is that it's still version 0.x, although is seeing activity.
The 'pure' python implementation is at https://github.com/rtfd/CommonMark-py
Should this also apply to git.sr.ht / markdown tables? Because they don't get rendered at https://git.sr.ht/~z3ntu/openrazer
Just switched to a faster markdown implementation, will have to do some more work to get GFM working again.
Bump.
We're still using misaka, which is not good, and bugs about markdown formatting are piling up from multiple bug trackers, so I think it would be a good idea to replace misaka with something else. See https://todo.sr.ht/~sircmpwn/sr.ht/223, https://todo.sr.ht/~sircmpwn/sr.ht/195, https://todo.sr.ht/~sircmpwn/sr.ht/188, https://todo.sr.ht/~sircmpwn/sr.ht/127, https://todo.sr.ht/~sircmpwn/git.sr.ht/201, https://todo.sr.ht/~sircmpwn/git.sr.ht/191, and that was only a cursory search.
As mentioned before, there is https://github.com/rtfd/CommonMark-py, and I found https://pypi.org/project/marko, which implements CommonMark, adds additional extensions and has GFM support. However, it clearly states that it's a bit slower than other processors; I don't know whether this is going to be an issue.
I don't program often in Python, but I am willing to try to rewrite https://git.sr.ht/~sircmpwn/core.sr.ht/tree/master/srht/markdown.py to use marko instead. There will probably be a lot of bugs, but I can put forth a first implementation.
Another solution to make it faster might be a switch that part to Go, something like https://github.com/gomarkdown
Why not just use cmark-gfm, the C library used by GitHub? I've used the Python bindings for personal projects and it works great. Just run
cmarkgfm.github_flavored_markdown_to_html(markdown_text)There is also an option to strip all HTML and support for footnotes using the
CMARK_OPT_FOOTNOTESoption. I can submit a preliminary pull request, although maybe we should add some Markdown tests to core.sr.ht before doing that. What do you all think?
There's also quite a bit of processing that goes on for things like headers and images. If cmark-gfm can support hooks that allow modifying the Markdown/HTML being processed, that would work, but otherwise see my current PR https://lists.sr.ht/~sircmpwn/sr.ht-dev/patches/10449.
We're using CommonMark now.