Closed nawroth closed 8 years ago
:+1: I love this feature in the Chrome extension. I use it all the time.
I think you pointed me to the code over there already. It's such a low hanging fruit, I should just get it done.
@mojavelinux This reminds me ... should source-language
affect plain literalblocks, which are not really source
blocks?
I'm actually not sure why the language
attribute in the document isn't picked up when the page is rendered without overrides: http://gist.asciidoctor.org/?github-asciidoc%2Fasciidoc%2F%2Fdoc%2Fsource-highlight-filter.txt#_source_code_paragraphs
But anyhow, locking source-language
from the URL works fine.
If language
is set as well, it will win. (expected?)
I added pygments
as highlighter to see if the sanity check still worked.
(see the output in the console)
But anyhow, locking source-language from the URL works fine. If language is set as well, it will win. (expected?)
I suppose so. language
is the deprecated attribute and source-language
is now preferred. We're missing a test in core to validate what happens if both are specified. I guess we could say it's a bit undefined atm.
should source-language affect plain literalblocks, which are not really source blocks?
It shouldn't, though we are planning a change in this area. See https://github.com/asciidoctor/asciidoctor/issues/1117. Even then, if a block is marked as listing
or literal
it should not get source highlighting.
Ok, I'll leave the literal blocks out for now, as the HTML generated for the different variants is identical. I tried to collect some variations of this here: http://gist.asciidoctor.org/?b60dad2c320ecbea4694
This would be useful for sharing documents with different settings without having to alter the document itself. This would also come in very handy in testing the rendering of for example the AsciiDoc User Guide.