I'm replying a year late to this thread, post-merge, because I've
discovered it breaks interaction with the highlight.js library(
https://highlightjs.org/) and therefore my workflow, which depends on
highlightjs via reveal.js.
My difficulty is with the current version of ~org-html-do-format-code~,
which currently surrounds each loc with a ~<code>~ tag and potentially some
classes:
(format "<code%s>%s</code>"
(if num-start
(format " data-ox-html-linenr=\"%s\"" line-num)
"")
loc)
On Mon, Oct 15, 2018 at 4:07 AM Nik Clayton <n...@ngo.org.uk> wrote:
> Hi,
>
> I'd like to propose a couple of changes / enhancements to how org-export
> exports some data in to HTML files to make it slightly easier to style
> those files.
>
> The first is re line-numbers.
>
> At the moment those get exported as content in the HTML, although they're
> really additional metadata. Amongst other things, this means that if you
> copy/paste from the output you get the line numbers included in the text
> that's copied.
>
> CSS supports arbitrary counters that can be associated with content,
> starting from an arbitrary value. My current hack that sort of works is the
> following CSS:
> .....
> and a change to org-html-do-format-code to wrap each line in its own
> <code>...</code> element:
>
> ...
> ;; Transcoded src line.
> (format "<code>%s</code>" loc)
> ...
>
> a) Does that sound reasonable?
> b) Should this replace the current approach, or be an option that can be
> toggled by a customisation?
>
> I agree that thisseems to make sense for many applications. But
highlight.js is a very widely-used highlighting library that expects
exactly one ~<code>~ tag inside a given ~<pre>~ block. The additional
~<code>~ tags that org now generates on html export break highlight in
ways I don't believe can easily be fixed. I wonder if we could revisit the
idea of adding a user option that would allow this feature to be switched
off? If this would be of general use I can prepare a patch.
Thanks,
Matt
