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.
Hi Roland,
Roland Kaufmann roland.kaufm...@gmail.com writes:
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
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
Roland Kaufmann roland.kaufm...@gmail.com writes:
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
Sorry for taking a very long time to respond.
Roland Kaufmann roland.kaufm...@gmail.com writes:
(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
[ Please include me in the replies, as I'm not subscribed to emacs-orgmode. ]
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
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
