From: Thibault Marin <thibault.marin@gmx.com>
To: org mode <emacs-orgmode@gnu.org>
Subject: Possible bug with coderef highlighting in HTML export
Date: Sun, 03 Dec 2017 04:35:30 -0600 [thread overview]
Message-ID: <87lgikp099.fsf@dell-desktop.WORKGROUP> (raw)
Hi all,
I am using Org mode version 9.1.3 (release_9.1.3-216-g259656 @
/.../org-mode/lisp/) and I am experiencing an issue with the exported
HTML of the following org file:
,----
| this links get highlighted [[(link0)]].
|
| this link does not get highlighted [[(link1)]].
|
| #+begin_src emacs-lisp -r
| 0(ref:link0)
| #+end_src
|
| #+begin_src emacs-lisp -r
|
| 1(ref:link1)
| #+end_src
`----
The relevant HTML output is:
,----
| <p>
| this links get highlighted <a href="#coderef-link0" class="coderef" onmouseover="CodeHighlightOn(this, 'coderef-link0');" onmouseout="CodeHighlightOff(this, 'coderef-link0');">1</a>.
| </p>
|
| <p>
| this link does not get highlighted <a href="#coderef-link1" class="coderef" onmouseover="CodeHighlightOn(this, 'coderef-link1');" onmouseout="CodeHighlightOff(this, 'coderef-link1');">1</a>.
| </p>
|
| <div class="org-src-container">
| <pre class="src src-emacs-lisp"><span id="coderef-link0" class="coderef-off">0</span>
| </pre>
| </div>
|
| <div class="org-src-container">
| <pre class="src src-emacs-lisp">1
| </pre>
| </div>
`----
The issue is that the link to the line in the second source block is not
highlighted (it does not get the "coderef-off" span markup).
I tried to dig a little and it appears that `org-html-do-format-code' does not
handle empty lines at the beginning of a block. `(org-split-string "\n1")'
returns '("1") which looses the first empty line. The line reference received
via the `refs' variable (which has value ((2 . link1))) then becomes out of sync
with the `code' variable (split by lines) used for formatting of the code block.
I am not sure what is the best way to handle this:
1. Should the `refs' variable be built accounting for the top empty lines?
2. Alternatively, should the `org-html-do-format-code' and
`org-export-format-code' functions count the number of top empty lines and
adjust the line number accordingly?
3. Should top empty lines be completely deleted, before the `refs' array is
built?
I can try to propose a patch if the best option can be decided. Option 2 seems
relatively simple but feels like a hack.
I would appreciate any suggestions on how to best fix this.
Thanks in advance.
thibault
next reply other threads:[~2017-12-03 10:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-03 10:35 Thibault Marin [this message]
2017-12-03 14:08 ` Possible bug with coderef highlighting in HTML export Nicolas Goaziou
2017-12-04 0:41 ` Thibault Marin
2017-12-04 7:24 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lgikp099.fsf@dell-desktop.WORKGROUP \
--to=thibault.marin@gmx.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.