* Possible bug with coderef highlighting in HTML export
@ 2017-12-03 10:35 Thibault Marin
2017-12-03 14:08 ` Nicolas Goaziou
0 siblings, 1 reply; 4+ messages in thread
From: Thibault Marin @ 2017-12-03 10:35 UTC (permalink / raw)
To: org mode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible bug with coderef highlighting in HTML export
2017-12-03 10:35 Possible bug with coderef highlighting in HTML export Thibault Marin
@ 2017-12-03 14:08 ` Nicolas Goaziou
2017-12-04 0:41 ` Thibault Marin
0 siblings, 1 reply; 4+ messages in thread
From: Nicolas Goaziou @ 2017-12-03 14:08 UTC (permalink / raw)
To: Thibault Marin; +Cc: org mode
Hello,
Thibault Marin <thibault.marin@gmx.com> writes:
> 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).
Indeed.
> 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.
Option 1 seems the best way to go. Replacing `org-split-string' with
`split-string' is straightforward in this case. However, some issues
remain in `org-html-fontify-code'.
Thank you.
Regards,
--
Nicolas Goaziou
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Possible bug with coderef highlighting in HTML export
2017-12-03 14:08 ` Nicolas Goaziou
@ 2017-12-04 0:41 ` Thibault Marin
2017-12-04 7:24 ` Nicolas Goaziou
0 siblings, 1 reply; 4+ messages in thread
From: Thibault Marin @ 2017-12-04 0:41 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: org mode
[-- Attachment #1: Type: text/plain, Size: 148 bytes --]
Hi,
Hi the attach patch fixes the issue for me. Please let me know if you
have any suggestions.
As always, thanks for the guidance.
thibault
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-bug-in-HTML-export-of-code-blocks-with-starting-.patch --]
[-- Type: text/x-diff, Size: 1552 bytes --]
From a78dc91c9fd1aacb2c65f66ae5afa9ee25f56e01 Mon Sep 17 00:00:00 2001
From: thibault <thibault.marin@gmx.com>
Date: Sun, 3 Dec 2017 17:42:13 -0600
Subject: [PATCH] Fix bug in HTML export of code blocks with starting blank
lines
* lisp/ox-html.el (org-html-do-format-code): Preverse starting blank
lines when splitting code lines (use `split-string' instead of
`org-split-string').
(org-html-fontify-code): Preserve starting blank lines in returned
code string.
---
lisp/ox-html.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0e22c1699..90a6cede0 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2202,7 +2202,7 @@ https://github.com/hniksic/emacs-htmlize"))
(org-html-htmlize-region-for-paste
(point-min) (point-max))))))
;; Strip any enclosing <pre></pre> tags.
- (let* ((beg (and (string-match "\\`<pre[^>]*>\n*" code) (match-end 0)))
+ (let* ((beg (and (string-match "\\`<pre[^>]*>\n?" code) (match-end 0)))
(end (and beg (string-match "</pre>\\'" code))))
(if (and beg end) (substring code beg end) code)))))))))
@@ -2215,7 +2215,7 @@ alist between line numbers and references (as returned by
`org-export-unravel-code'), a boolean specifying if labels should
appear in the source code, and the number associated to the first
line of code."
- (let* ((code-lines (org-split-string code "\n"))
+ (let* ((code-lines (split-string code "\n"))
(code-length (length code-lines))
(num-fmt
(and num-start
--
2.14.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-12-04 7:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-12-03 10:35 Possible bug with coderef highlighting in HTML export Thibault Marin
2017-12-03 14:08 ` Nicolas Goaziou
2017-12-04 0:41 ` Thibault Marin
2017-12-04 7:24 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).