After updating to recent vrsions of oer-re-reveal and reveal.js, I find that code highlighting with highlight.js no longer works as expected. Each line of code now begins and ends with <code>....</code>. From what I can tell, those tags have been produced by org-html-format-code for a long time, and it worked fine. But reveal.js has also recently updated its version of highlight.js.
I can fix the issue for myself by deleting all the internal <code> tags. I'm not sure whether it would be OK to simply od a replace-regex-in-string on the variable code in org-re-reveal-src-block, or if it that might break other versions of reveal. What do you think? Also, are you able to reproduce this behaviour with reveal.js git or anyway at least 3.8.0?
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
Wrapping code in <pre><code>...</code></pre> is expected, but for the entire source block, not per line of code. I do not know why that happens in your case. Could you maybe provide a minimum Org example?
I included default, html, and reveal templates in the hopes that that could identify the source of the problem.... these additional code tages appeari n HTML export too, but without highlight.js and with default htmlization they look just fine.
I just pushed a new version, which treats the empty configuration strings of your file gracefully (but should be unrelated to your issue). The #+html_container: still confuses HTML export, though.
I attach my output, which seems fine (for Org version 9.2.3 and version 9.2.6). I produced that as follows in the source directory of org-re-reveal:
emacs -Q -L ./ -L ./org-plus-contrib/ -L ./htmlize/ ~/Downloads/test.orgM-: (require 'org-re-reveal)C-c C-e v v
If that works for you as well, something else in your configuration might be the cause.
thanks for fixing that issue! I'm afraid I just ran C-c C-e # to insert all of those options, and only looked at the source code afterwards to confirm the invalid html. I guess empty entries are interpreted as an empty string rather than as nil.
I feel pretty confident that the issue is not in org-re-reveal -- I am seeing an identical structure in vanilla HTML exports.
However, the HTMl in your file doesn't look quite right either -- the <pre> tag doesn't have a wrapping <code> tag inside it. Instead it looks like this:
Org mode version 9.2.5 (release_9.2.5-504-g3c24be @ /home/matt/src/org-mode/emacs/site-lisp/org/, so a little bit behind the current version. I'll see if updating makes any difference. updated to current git org-mode, i don't see any changes.
Actually, I just realized that you do not activate highlight.js, which needs something like this:
#+REVEAL_PLUGINS: (highlight)
Concerning the missing code in my upload: I'm not sure any more how I generated that. I had several HTML file versions. If I export now, <code class=" xml" > is present. However, org-re-reveal also has code paths for pre without code (not from me, I never saw a reason to change that).
You have reveal_klipsify_src:t, which could come with different syntax highlighting if the language was supported by klipse.
I forgot to mention: The packages org-plus-contrib and htmlize are part of the test infrastructure. They get downloaded when you run make check (or make allcheck)
For the new test file, I get pre without code; the code is wrapped in span elements with syntax highlighting by htmlize.
Actually, I just realized that you do not activate highlight.js, which needs something like this:
In the new simpletest.org I just evaluate the emacs-lisp src block before running.
You have reveal_klipsify_src:t, which could come with different syntax highlighting if the language was supported by klipse.
deleted that line in the new version
I forgot to mention: The packages org-plus-contrib and htmlize are part of the test infrastructure. They get downloaded when you run make check (or make allcheck)
neat. I haven't tried to run that yet; I see it pulls in org-plus-contrib from April of this year; I can't really tell what has hanged since then but maybe it's too old for the problem to have shown up yet?
Chuck Berry on the mailing list just pointed me to org-mode commit ded3d27b1468b878197e5fe55a70c5e13350ea27 which added the extra tags on June 4 of this year:
Commit ded3d27b1468b878197e5fe55a70c5e13350ea27Author: Nik Clayton <nik@ngo.org.uk>Date: Tue Jun 4 11:57:40 2019 +0200 ox-html: Wrap each line of a source block in a code element * lisp/ox-html.el (org-html-do-format-code): Wrap each line of a source block in a code element. This makes it straightforward to add custom decorations to each line using CSS :before and :after properties.
. This will for sure break highlight.js's expectations, so I think a filter is probably necessary in org-re-reveal-src-block, something like this
@@ -1695,7 +1695,10 @@ INFO is a plist holding contextual information. CONTENTS is unused." (or (org-re-reveal--frag-class frag info) (format " class=\"src src-%s\"" lang)) (or (org-re-reveal--frag-index findex) "")- label code))))))))+ label+ (replace-regexp-in-string+ "^<code>\\(.*\\)</code>$"+ "\\1" code )))))))))
What do you think?
it does mean that the new functionality would not be usable with highlight.js.
Thanks, I see this on the Git master. I did not think of this as your test file mentioned Org version 9.2.5, while mine was newer.
If we add this to org-re-reveal, the replacement should happen under control of a variable so that users can have the new Org behavior if they prefer. Alternatively, maybe you could ask on the Org mailing list whether they are willing to add a controlling variable to allow users to revert to old behavior as this breaks highlight.js? The HTML spec has just one code element around the entire code: https://www.w3.org/TR/html50/grouping-content.html#the-pre-element
I'll be traveling for a couple of days, so my responses will be delayed.
Just to be clear: Multiple code elements are allowed by the standard, just not suggested by example. So again alternatively, maybe highlight.js needs fixing?
And I wrote to the org list so we'll see if there's a reply on that end.
I'm not sure, but I think reveal uses a modified and still somewhat older version of highlight (9.11) so it might not be trivial to make use of any improvements to the underlying library.
I'm sorry also about the confusion with the org version number! I think that git master reports a version number that is even with the latest tag it knows about, and I hadn't pulled since 9.2.6 was released. But it seems that it took a while for Nik s change to be merged into a release.
I closed the issue for Highlight.js. Turns out, Highlight.js works correctly. The plugin version of reveal.js is causing the issue.
I just pushed org-re-reveal 2.8.0 (no Docker image yet). With that version, one can add the following to use a pure version of Highlight.js, which works.