As headlines are always lvl (indent) 0 I thought it would be clever to abuse
the lvl field to store the headline lvl. Well, here we are - it wasn't clever.
List items only end when their parent ends or they run into something that's
not indented enough - everything else becomes part of the list item. Abusing
the token.lvl field (indent) for the headline lvl means headlines look indented
to the list item parsing logic - i.e. they become part of the list item if the
headline has a high enough lvl. That should never happen - so let's get rid of
the hack and (re-)calculate the headline lvl when we need it.
Turns out Org mode supports image links natively and we don't have to go out of
spec!
From https://orgmode.org/manual/Images-in-HTML-export.html:
[...] if the description part of the Org link is itself another link, such as
‘file:’ or ‘http:’ URL pointing to an image, the HTML export back-end in-lines
this image and links to [...]
html does not support table separator rows as Org mode does. Emacs org export
simulates rows as defined by separators by wrapping all the rows between 2
separators into a separate tbody. The html spec is fine with that [0] so we
follow.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tbody
All tags are put on a line by themselves to help with visual
diffing. Apparently this extra cosmetic whitespace causes problems inside p
tags for ppl who want to use `white-space: pre`. Not much hurt for visual
diffing in removing cosmetic whitespace for just p tags and can't think of
anything that would break because of this right now. So let's do it and wait
for things to break.
inside src example blocks lines starting with `\s*,` are escaped - i.e. org
mode will not try to parse them as e.g. a headline. We don't want to render the
escape commata to html so let's take them out - and put them back in before
rendering to org. Doing it this way allows us to render them correctly even
when the input did not include them.
see https://orgmode.org/manual/Literal-Examples.html#Literal-Examples
While example blocks do not render inline markup and are thus parsed raw in
some way, their contents are not literal html and thus still need to be html
escaped.
delimiters are not always 2 in length - $ being the exception. Also we have to
make sure to handle both $ and $$ delimiters.
Not proud of this solution but can't think of anything simpler right now - will
come back to this later hopefully.
The org mode toc OPTION does not just support true/false - it also allows
specifying the max headline level [1] to be included in the toc.
[1] headline level as seen in org mode - not the html tag level
We want original whitespace to be rendered in some cases (e.g. verse
blocks). This requires information about the original whitespace to be
preserved during paragraph parsing. As html ignores (collapses) whitespace by
default we don't have to adapt the html writer and can just selectively enable
rendering of the preseverved whitespace wherever we want it using
css (white-space: pre).
To differentiate meaningful whitespace from document structure based
indentation (i.e. list item base indentation) we need to introduce
document.baseLvl. A paragraph by itself does not have enough information to
differentiate both kinds of whitespace and needs this information as context
[0].
As we're already touching list indentation i went along and improved (fixed?)
descriptive list item indentation rendering in the org writer (it should match
emacs tab behavior - i.e. indent subsequent lines up to the `:: `).
[0] e.g. list items can contain blank lines - a paragraph starting with a blank
line would not know that it is part of a list item / has a base indentation -
the blank line would suggest a baseLvl of 0.
fuzzed index out of range and moved range check into for condition as \\
followed by spaces at the end of the inline text should not be turned into an
ExplicitLineBreak (just like \\ not followed by spaces).
now that i'm already looking at it due to the bug leenzhu found why not put the
</dt> on a separate line to match the convention - looks better to me; doesn't
change anything.
writer.footnotes must be a pointer as we copy the writer in nodesAsString() and
can thus end up modifying the footnotes.list slice without it being reflected in
the original writer (i.e. when the backing array of the slice changes).
I didn't consider that all newlines in the pre block will be printed and we
thus shouldn't wrap html that has it's tags on separate lines (i.e. contains
superfluous newlines) - wrapping in a div less accurately represents
org-html-export but it provides the same information and gives us more freedom
in the return value of HighlightCodeBlock as well as allowing us to keep the
html tags on new lines (consistency).
I went with 0 based numbering because it was easier but after looking at the
results 0 based numbering looks bad to me... let's start with 1 like everyone
else as it's just a few more lines of code.
- Remove unused footnote section title option
- Move away from maintaining a list of footnotes in the document (only needed
for html export, potential maintainance overhead when modifying the document)
and rather only build it on export when required.
- HTML export: Rename all footnotes to numbers (so we can support anonymous
footnote references by assigning them a number) and export footnotes in order
of reference, not definition. The implementation of this makes it natural to
also stop exporting unused footnote definitions so we do that as well.
It's possible for the input to end right after the explicit line break,
i.e. after the second \. This currently leads to an out of range index into
input (as the for loop starts with start+2 and [start:start+1] is the \\).
Unlike the other BufferSettings, #+OPTIONS: specifies multiple options and we
cannot just look it up in either BufferSettings or DefaultSettings - both have
to be checked
Hugo has some hardcoded checks that have to be fulfilled in its Table of
Contents extraction workflow (helpers/content ExtractTOC). It's easier this
way...
- Footnotes separator rather than headline to get around i18n
- Warn on footnote redefinition
- Do not export footnote definitions at point of definition, only in the
footnote section.
- Do not automatically exclude Footnotes section to get around possibly hiding
other content of such a section - and i18n.
The user has the choice of explicitly hiding the section via a :noexport:
tag.
and some other refactoring
