[O] Markup problems when using references in source fragments (was: Markup on same line as text)
On February 27th I submitted a patch proposal to fix HTML export of line number references in source code fragments. The discussion leading up to the patch can be found in the thread: http://thread.gmane.org/gmane.emacs.orgmode/35810 As far as I can see, it is not in the source tree as of revision 62d4dd, but the problem still remains. I am grateful for feedback on its lackings, if the patch is deemed unsatisfactory in any way. In case it simply got lost amidst all the other traffic, I resubmit it, updated so it applies to the current revision. -- Roland. From 98e2a586eb0e911ec6b5bedeec4af5f00ee2bf6c Mon Sep 17 00:00:00 2001 From: Roland Kaufmann rlndkfmn+orgm...@gmail.com Date: Sun, 27 Feb 2011 20:52:31 +0100 Subject: [PATCH] Fix markup problems when using references in source fragments * org-exp.el (org-export-format-source-code-or-example): fontify one line at the time to avoid partial overlap between fontification and reference markup. --- lisp/org-exp.el | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 9a35b00..dbcf105 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -2446,6 +2446,15 @@ in the list) and remove property and value from the list in LISTVAR. (defvar org-export-latex-listings-options) ;; defined in org-latex.el (defvar org-export-latex-minted-options) ;; defined in org-latex.el +(defun org-remove-formatting-on-newlines-in-region (beg end) + Remove formatting on newline characters + (interactive r) + (save-excursion +(goto-char beg) +(while (progn (end-of-line) ( (point) end)) + (put-text-property (point) (1+ (point)) 'face nil) + (forward-char 1 + (defun org-export-format-source-code-or-example (lang code optional opts indent caption) Format CODE from language LANG and return it formatted for export. @@ -2532,6 +2541,8 @@ INDENT was the original indentation of the block. (funcall mode) (fundamental-mode)) (font-lock-fontify-buffer) + ;; markup each line separately + (org-remove-formatting-on-newlines-in-region (point-min) (point-max)) (org-src-mode) (set-buffer-modified-p nil) (org-export-htmlize-region-for-paste -- 1.7.1
Re: [O] Markup problems when using references in source fragments
On 2011-05-11 21:51, Bernt Hansen wrote: Both the new and old patch are on the patchwork server waiting to be addressed. Oops, sorry my bad. I didn't realize that! However, only the discussion from the first thread: http://patchwork.newartisans.com/patch/525/ is revelant. The patch which is listed there should *not* be applied. A second and corrected patch was attached in the last message, but it seems to not have been picked up by the framework. How do I replace the patch above with the code from: http://patchwork.newartisans.com/patch/802/ -- Roland.
[Orgmode] Re: [PATCH] Markup on same line as text
Sorry for taking so long to come back to this; I had some unrelated problems with my system. Please let us know if there is a useful way to generalize the workaround presented earlier in the thread. Attached is against the latest git tree for org-mode a patch which I believe does the trick. (This supersedes the previous patch against htmlize.el). Thanks to Hrvoje for suggesting this approach and providing the code to reset the face attribute. -- Roland. 0001-Markup-on-same-line-as-text.patch Description: Binary data ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Markup on same line as text
htmlize doesn't operate on the level of syntax-based fontification, it examines the display-related properties attached to buffer text (not necessarily by font-lock) and renders them into the corresponding HTML. Good point. And, as you point out, it is probably better to deal with the problem by removing the formatting on the newlines (probably right after font-lock-fontify-buffer in org-export-format-source-code-or-example) in the temporary buffer that is htmlize'd, reducing the chance of any unintended consequences. I'll try this approach and see how it turns out (i.e. proposal for change in htmlize dropped). Thank you for the feedback! -- Roland. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH] Markup on same line as text
Your patch may work in this particular case, but the idea behind htmlize is to describe the state of the buffer. If a property ends after the newline, it is intended that the generated HTML reflect The philosophical question is then: Is the newline character part of the syntax construct that is being fontified, or rather a formatting code that should be kept separate? Being whitespace it (mostly) doesn't matter visually, which makes it an easy choice to include in tokens to preserve formatting continuity between lines. However, any further line processing by other modules is complicated significantly if the terminator is put inside the markup. I am not familiar with org-mode, so I will need a description of exactly how to reproduce this bug. Specifically I don't know how to put a reference on the next line. This Elisp will create/overwrite a buffer called foo.org in the /tmp directory containing problematic code and export it to foo.html: (let ((filename (expand-file-name foo.org temporary-file-directory))) (switch-to-buffer (find-file-noselect filename)) (erase-buffer) (insert * #+BEGIN_SRC emacs-lisp (let ((x 42)) ; meaning of l.u.e. (print x)) ; (ref:2) #+END_SRC) (save-buffer) (org-mode) (org-export-as-html nil)) -- Roland. ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Markup on same line as text
I just discovered a problem with colorization and references in code snippets due to the way org-mode and htmlize interact. Consider the org-mode fragment: #+BEGIN_SRC emacs-lisp (let ((x 42)) ; meaning of l.u.e. (print x)) ; (ref:2) #+END_SRC Without the reference on line 2, doing an org-export-as-html would generate markup like this: (let ((x 42)) span style=comment; meaning of l.u.e. /span (print x)) Note that htmlize put the newline character on the end of the first line together with the text of the comment, both which is put inside the span. The closing tag of the span to colorize the comment thus ends up on the next line. When a reference is put on the next line, org-mode will subsequently add markup to highlight each line, so the markup ends up like this: (let ((x 42)) span style=comment; meaning of l.u.e. span id=ref-2/span (print x))/span ^^^ The first closing tag is really the end of the comment which is spilled to the next line, but it erraneously closes the id span. The color of the comment then proceeds to the end of the second line, where the id span was to close. To remedy this, I wrote a patch which postpone writing the newline to the html buffer until after the closing tag has been emitted. The patch is attached and should be applicable to the current Git repository. It should be applicable to version 1.37 of htmlize.el as well, with the command `patch -p3 0001-Markup-on-same-line-as-text.patch`. I refactored the insert-text functions so that they return the markup that should be applied instead of doing the insertion itself, and then let this go through a new function add-markup which puts the tags around the text, putting any trailing newline in the text at the very end, before the main htmlize-buffer-1 does the actual insertion in the buffer. I have tested this with all three kinds of htmlize-output-type, and it seems to give the expected result. -- Roland. From 86f1508f58dd304471d768481944d34e220e24f1 Mon Sep 17 00:00:00 2001 From: Roland Kaufmann rlndkfmn+orgm...@gmail.com Date: Thu, 6 Jan 2011 11:22:49 +0100 Subject: [PATCH] Markup on same line as text MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=1.7.3.1.msysgit.0 This is a multi-part message in MIME format. --1.7.3.1.msysgit.0 Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit * contrib/lisp/htmlize.el: Markup on same line as text Newline was considered to be a part of the text to be marked up; thus the closing tag was put on the next line. Since org-mode does line processing on the result, the line number span was closed prematurely by this tag and the formatting erraneously extended through the next line. This fix replaces the insert-text functions with new get-markup variants which return a pair (start-tag end-tag) for the appropriate formatting. The newline is then removed from the text with `split-trailing-newline` and appended again after the close tag in `add-markup`. The text is sent to the buffer after this processing instead of in each behavioral insert-text function. The names of the functions are changed so reflect that the signatures are different. --- contrib/lisp/htmlize.el | 67 ++- 1 files changed, 37 insertions(+), 30 deletions(-) --1.7.3.1.msysgit.0 Content-Type: text/x-patch; name=0001-Markup-on-same-line-as-text.patch Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename=0001-Markup-on-same-line-as-text.patch diff --git a/contrib/lisp/htmlize.el b/contrib/lisp/htmlize.el index 5f4cb5b..f952b80 100644 --- a/contrib/lisp/htmlize.el +++ b/contrib/lisp/htmlize.el @@ -1209,7 +1209,7 @@ property and by buffer overlays that specify `face'. ;; `htmlize-buffer-1' calls a number of methods, which indirect to ;; the functions that depend on `htmlize-output-type'. The currently ;; used methods are `doctype', `insert-head', `body-tag', and -;; `insert-text'. Not all output types define all methods. +;; `get-markup'. Not all output types define all methods. ;; ;; Methods are called either with (htmlize-method METHOD ARGS...) ;; special form, or by accessing the function with @@ -1347,18 +1347,18 @@ it's called with the same value of KEY. All other times, the cached (insert htmlize-hyperlink-style --\n/style\n)) -(defun htmlize-css-insert-text (text fstruct-list buffer) - ;; Insert TEXT colored with FACES into BUFFER. In CSS mode, this is - ;; easy: just nest the text in one span class=... tag for each - ;; face in FSTRUCT-LIST. - (dolist (fstruct fstruct-list) -(princ span class=\ buffer) -(princ (htmlize-fstruct-css-name fstruct) buffer) -(princ \ buffer)) - (princ text buffer) - (dolist (fstruct fstruct-list) -(ignore fstruct) ; shut up the byte-compiler -(princ /span buffer))) +(defun htmlize-css-get-markup (fstruct
