You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: