-
-
Notifications
You must be signed in to change notification settings - Fork 6.6k
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
chore(docs): enabled syntax highlighting #6286
Conversation
... for better readability
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a problem with going down this route, but I think we should change codesnippets in all the files under docs/ if we decide to. Assuming there are no -1's to this: @0xflotus would you be interested in expanding this PR, or would you like help on that part?
For sure, I will go through the docs and will enable code highlight where possible, right? |
On 7 Dec 2020, at 20:27, 0xflotus ***@***.***> wrote:
For sure, I will go through the docs and will enable code highlight where possible, right?
Correct. Let's wait a little while to see if other reviewers have differing opinions before spending all that time, but if not let's go. Feel free to tag me in a comment when there is an updated PR so I don't miss the notification to review it.
|
I'm all for it. Just two things to keep in mind:
|
If we only think about |
It shouldn't be any problems, no. I'm just being cautious so that we don't run ahead and make a lot of changes that don't work well on the site. I presume code highlighting won't be a problem. On the website we use the github-markup tool (on Debian Linux from the package |
in CODE_STYLE.md
in INSTALL.md
in INTERNALS.md
in MANUAL.md
in TheArtOfHttpScripting.md
in VERSIONS.md
I think I went through all Markdown files in the |
So the renderer takes the ```c
// c code not as code highlight hint? So we can't use this PR, without tuning the renderer? :/ |
I think it would be unfortunate to use a markdown format we cannot convert to HTML ourselves. I can't say I know for sure that the website's representation for these documents is more important than GitHub's right now, but as a project policy I think its a bad precedent to assume GitHub for something like this. I think we as a project should live and work as if GitHub dies tomorrow, we still host our main documents on the site and we could switch to and use another source code service in jiffy. Thus, "proprietary" GitHub markdown format should be avoided until we can use them outside of GitHub. The questions then become:
|
Jan pointed out there's an API for this: https://docs.github.com/en/free-pro-team@latest/rest/reference/markdown ... which seems to want the document in JSON as input!? |
|
Thanks @Frederik-Baetens. With pandoc and this PR, the same piece I showed above looks fine. I'm pretty sure it can also be further polished by tweaking the CSS: |
As of curl/curl-www@d79508c just pushed, the website is now rendering markdown with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Once it lands and renders onto the website we'll see if we need to tweak anything.
Thanks! |
... for better readability