Before this commit, if an org document was titled "Title here", the
first line of HTML output would be as follows:
<h1 class="title"><p>Title here\n</p></h1>
This commit changes the HTML writer to instead output the following:
<h1 class="title">Title Here</h1>
I conversatively modified the code, so there might be more cases where
elements should be omitted from the title.
This reverts commit bf7f957af2.
We still have to manually install it for now but we don't have to fuck around
with env vars anymore. github actions still defaults to go 1.15 [1]. Whatever.
[1]
```
ls -lisah $(which go)
108022 0 lrwxrwxrwx 1 root root 42 Mar 18 22:15 /usr/bin/go ->
/opt/hostedtoolcache/go/1.15.10/x64/bin/go
```
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.
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.
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.
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
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).
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.
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
this introduces the PropertyDrawer node to make it easier to access the
properties associated to a headline - normal drawers don't parse their content
into kv pairs
Org mode does not care where those tokens are when it comes to the
export (afaict). We'll do the same.
(They should only be in the first line of a list item or a headline)
Org mode separates kvs not as initially assumed by whitespace (~ csv) but
rather at keywords (~ :\w+).
This is still not replicating Org mode behaviour though as I decided against
attributes ignoring multi-definitions. Instead we stack their
values (and those existing on the element) for certain attributes (class, style
for now).
e.g.
[[foo]]
would become <foo class="a"> in Org mode but becomes <foo class="a b"> with
go-org.
https://scripter.co/how-do-i-write-org-mode/
Prefer “Org mode” to “Org-mode” or “org-mode”. This is simply because it reflects an existing convention in The Emacs Manual which consistently documents mode names in this form - “Text mode”, “Outline mode”, “Mail mode”, etc.
While adding another test case from the goorgeous issues it became clear that
inline markup and html entity replacement were erronously applied to raw text
elements like inline code =foo=, src/example/export blocks, example lines,
etc.
To correctly handle those cases in both org and html exports a new
parseRawInline method had to be added.
Also some misc html export whitespace fixes and stuff
including org files is more complex - e.g. footnotes need to be namespaced to
their source file. org does this by prefixing each included files footnotes
with a number - but even that is not enough as it doesn't guarantee
uniqueness.
As I don't have a usecase for it, I'll avoid the additional complexity for
now.
Also dismissed implementing colgroups for now - had it but didn't like the
added complexity for a very questionable benefit - i've actually never used
that feature of org tables...
- was missing spaces between attributes when rendering to org
- was duplicating attributes when rendering to html - now we join / replace
attributes depending on the name - for now only class & style are appended
... hopefully correctly
This will hopefully improve ease of developing (more granular test results) and
prepares us for adding example org->html renders for gh-pages
