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

[FR] Alternative setting for highlightjs #3189

Open
redtide opened this issue Apr 20, 2023 · 3 comments
Open

[FR] Alternative setting for highlightjs #3189

redtide opened this issue Apr 20, 2023 · 3 comments
Labels
Theme-mkdocs Issues specifically involving the mkdocs theme. Theme-readthedocs Issues specifically involving the readthedocs theme.

Comments

@redtide
Copy link

redtide commented Apr 20, 2023

Current:

highlightjs: true
hljs_languages:
- cpp
hljs_style: github

Alternative:

highlightjs:
  languages:
     builtin:
     - cpp
     extra (or custom or whatever):
     - relative or abs url to customlanguage.min.js
  style: github

or if #2171 would be (finally) a thing (or not, needs some strategy to support also only 1 mode by defining 1 of 2):

highlightjs:
  ...
  style:
    light: github
    dark: github-dark
@oprypin
Copy link
Contributor

oprypin commented Jun 17, 2023

That's a fine suggestion for a refactor (just makes it looks nice), but what's the practical benefit that would justify incompatibility or duplication?

@tomchristie
Copy link
Member

tomchristie commented Apr 12, 2024

Really it'd be neater if highlightjs (or whatever other alternative) was included through overriding the template styles/libs blocks, rather than through config. Perhaps something to move towards as part of #3190.

@tomchristie tomchristie added Theme-mkdocs Issues specifically involving the mkdocs theme. Theme-readthedocs Issues specifically involving the readthedocs theme. labels Apr 12, 2024
@redtide
Copy link
Author

redtide commented Apr 12, 2024

Really it'd be neater if highlightjs (or whatever other alternative) was included through overriding the template styles/libs blocks, rather than through config. Perhaps something to move towards as part of #3190.

in general you say "less integrations, more modularity", I totally agree that that's a better choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Theme-mkdocs Issues specifically involving the mkdocs theme. Theme-readthedocs Issues specifically involving the readthedocs theme.
Projects
None yet
Development

No branches or pull requests

3 participants