From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: ox-html: add option to restore old src block behaviour? Date: Thu, 19 Sep 2019 12:33:20 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a4b4160592ea8358" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:44217) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iAzN9-0006kb-JY for emacs-orgmode@gnu.org; Thu, 19 Sep 2019 12:33:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iAzN8-0006BG-6e for emacs-orgmode@gnu.org; Thu, 19 Sep 2019 12:33:35 -0400 Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]:45480) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iAzN7-00069k-Uu for emacs-orgmode@gnu.org; Thu, 19 Sep 2019 12:33:34 -0400 Received: by mail-pf1-x433.google.com with SMTP id y72so2632372pfb.12 for ; Thu, 19 Sep 2019 09:33:33 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Org Mode --000000000000a4b4160592ea8358 Content-Type: text/plain; charset="UTF-8" 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 ~~ 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 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 --000000000000a4b4160592ea8358 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
reiterating a question I posted to an old thread that= may have gotten lost.

Over the summer, commit ded= 3d27b1468b878197e5fe55a70c5e13350ea27 by Nik Clayton was merged to master. = It's a one-line change that adds new ~<code>~ tags around each li= n of code in html export of source blocks.=C2=A0 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 ex= pects the old behaviour (see https://gitlab.com/oer/org-re-reveal/issues/27).=C2=A0 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/headli= ne-settable property -- that restores the old behaviour when desired.=C2=A0= If this would be welcome, I could do it. I know org already has a bewilder= ing 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
--000000000000a4b4160592ea8358--