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

Implement highlight.js across website code tags #1633

Closed
julioest opened this issue Feb 13, 2025 · 3 comments
Closed

Implement highlight.js across website code tags #1633

julioest opened this issue Feb 13, 2025 · 3 comments
Assignees

Comments

@julioest
Copy link
Collaborator

We need to adopt highlight.js as the default syntax highlighter for code tags across both the website and library documentation (regardless of document type: asciidoctor, qbk, etc.). The goal is to ensure consistent, visually appealing code presentation wherever possible, while acknowledging that some legacy cases might remain unchanged due to technical limitations.

Originally, we considered implementing this change through the boostlook project. However, we believe that is more effective to handle the conversion on the Django side within the website‑v2 project.

This initiative is inspired by this discussion.

@sdarwin
Copy link
Collaborator

sdarwin commented Feb 13, 2025

"on the Django side"

If the modification can be made close to the source, as Julio suggested: ( adjust the b2 configuration to include this info in some way: asciidoctor-attribute=source-highlighter=highlight.js ), that part would not be in either boostlook or django, but rather in release-tools. You may send pull requests there. (Or, to the superproject. Or to the b2 project). Or at least, those are options.
keeping in mind, it's good to try to find ways to keep all method synced, so it appears 'correct', at whichever level it is built. Such as, a PR to an individual boost library repo, adjusts the appearance at that level, and everywhere else also.

@daveoconnor
Copy link
Collaborator

Yeah, The CI process for building the docs seems like it might be the best place to make the change to me.

Changing it in website-v2 would be more complicated with the markup already baked into the code snippets at that stage. It would require stripping those using beautiful soup, and probably having to handle all sorts of different variations again for the different highlighters used by the lib devs.

@julioest
Copy link
Collaborator Author

This issue is being closed because the work will be done elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

3 participants