From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Price Subject: Re: (no subject) Date: Sun, 15 Sep 2019 17:06:10 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000fa661005929ddb5e" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:49484) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9biz-0007Qw-0M for emacs-orgmode@gnu.org; Sun, 15 Sep 2019 17:06:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i9bix-00040w-Li for emacs-orgmode@gnu.org; Sun, 15 Sep 2019 17:06:24 -0400 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]:38296) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i9bix-00040M-FE for emacs-orgmode@gnu.org; Sun, 15 Sep 2019 17:06:23 -0400 Received: by mail-pl1-x62a.google.com with SMTP id w10so4744804plq.5 for ; Sun, 15 Sep 2019 14:06:22 -0700 (PDT) In-Reply-To: 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: Nik Clayton Cc: emacs-orgmode --000000000000fa661005929ddb5e Content-Type: text/plain; charset="UTF-8" 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 ~~ tag and potentially some classes: (format "%s" (if num-start (format " data-ox-html-linenr=\"%s\"" line-num) "") loc) On Mon, Oct 15, 2018 at 4:07 AM Nik Clayton 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 > ... element: > > ... > ;; Transcoded src line. > (format "%s" 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 ~~ tag inside a given ~
~ block. The additional
~~ 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

--000000000000fa661005929ddb5e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm replying a year late to this thread, post-mer=
ge, 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.=C2=
=A0 

My difficulty is with the current version=
 of ~org-html-do-format-code~, which currently surrounds each loc with a ~&=
lt;code>~ tag and potentially some classes:

(fo=
rmat "<code%s>%s</code>"
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (if num-start
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 (format " data-ox-html-linenr=3D\"%s\"" l=
ine-num)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 "")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loc)


On Mon, Oct 15, 2018 at 4:07 AM Nik Clayton <nik@ngo.org.uk> wrote:
Hi,

I'd l=
ike 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 th=
ey'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 co=
unters that can be associated with content, starting from an arbitrary valu=
e. My current hack that sort of works is the following CSS:
=C2=A0=
.....
and a change to org-html-do-format-code to wra=
p each line in its own <code>...</code> element:<=
/div>

...
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; T=
ranscoded src line.
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (f=
ormat "<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 hi=
ghlight.js is a very widely-used highlighting library that expects exactly =
one ~<code>~ tag inside a given ~<pre>~ block. The additional ~=
<code>~ tags=C2=A0 that org now generates on html export break highli=
ght in ways I don't believe can easily be fixed. I wonder if we could r=
evisit the idea of adding a user option that would allow this feature to be=
 switched off?=C2=A0 If this would be of general use I can prepare a patch.=
 

Thanks,
Matt


--000000000000fa661005929ddb5e--