ox-html: add option to restore old src block behaviour?

ox-html: add option to restore old src block behaviour?

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

reiterating a question I posted to an old thread that may have gotten lost.

Over the summer, commit ded3d27b1468b878197e5fe55a70c5e13350ea27 by Nik
Clayton was merged to master. It's a one-line change that adds new ~<code>~
tags around each lin of code in html export of source blocks.  It's useful
because it allows individual lines to be addressed directly by CSS.

However, at least one very common syntax highlighter,
https://highlinghtjs.org, expects just a single <code> tag, as do other
common CSS frameworks. These often leave odd borders or background color
disruptions which somewhat distort the view of the code. There's also a
funny conflict with `org-re-reveal`, which expects the old behaviour (see
https://gitlab.com/oer/org-re-reveal/issues/27).  It would in principal be
possible to fix these issues directly in CSS, but it might be much more
practical to have an option -- a defvar or a file/headline-settable
property -- that restores the old behaviour when desired.  If this would be
welcome, I could do it. I know org already has a bewildering number of
options,though,and the code change would be oddly a number of times as
large as the substantive change of that commit, os thought I'd check first.
Thanks!

Matt

[-- Attachment #2: Type: text/html, Size: 1477 bytes --]

Re: ox-html: add option to restore old src block behaviour?

[Bastien]

Hi Matt,

Matt Price <moptop99@gmail.com> writes:

> However, at least one very common syntax highlighter, https://
> highlinghtjs.org, expects just a single <code> tag, as do other
> common CSS frameworks. These often leave odd borders or background
> color disruptions which somewhat distort the view of the code.
> There's also a funny conflict with `org-re-reveal`, which expects the
> old behaviour (see https://gitlab.com/oer/org-re-reveal/issues/27). 
> It would in principal be possible to fix these issues directly in
> CSS, but it might be much more practical to have an option -- a
> defvar or a file/headline-settable property -- that restores the old
> behaviour when desired.  If this would be welcome, I could do it. I
> know org already has a bewildering number of options,though,and the
> code change would be oddly a number of times as large as the
> substantive change of that commit, os thought I'd check first.

Yes, an option makes sense here -- can you provide one that allows to
restore the old behavior (and avoid all those <code>...</code> lines)?

Thanks in advance!

-- 
 Bastien

Re: ox-html: add option to restore old src block behaviour?

[Jens Lechtenboerger]

On 2020-02-11, at 16:40, Bastien wrote:

> Matt Price <moptop99@gmail.com> writes:
>
>> However, at least one very common syntax highlighter, https://
>> highlinghtjs.org, expects just a single <code> tag, as do other
>> common CSS frameworks. These often leave odd borders or background
>> color disruptions which somewhat distort the view of the code.
>> There's also a funny conflict with `org-re-reveal`, which expects the
>> old behaviour (see https://gitlab.com/oer/org-re-reveal/issues/27). 
>> It would in principal be possible to fix these issues directly in
>> CSS, but it might be much more practical to have an option -- a
>> defvar or a file/headline-settable property -- that restores the old
>> behaviour when desired.  If this would be welcome, I could do it. I
>> know org already has a bewildering number of options,though,and the
>> code change would be oddly a number of times as large as the
>> substantive change of that commit, os thought I'd check first.
>
> Yes, an option makes sense here -- can you provide one that allows to
> restore the old behavior (and avoid all those <code>...</code> lines)?

Hi Bastien,

that issue has been resolved:
https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00099.html

Best wishes
Jens

Re: ox-html: add option to restore old src block behaviour?

[Bastien]

Hi Jens,

Jens Lechtenboerger <jens.lechtenboerger@fsfe.org> writes:

> that issue has been resolved:
> https://lists.gnu.org/archive/html/emacs-orgmode/2019-10/msg00099.html

great, thanks for confirming.

-- 
 Bastien