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
Until now the footnotes section was parsed but not included in the resulting
AST - his required rebuilding it in the OrgWriter. It feels cleaner to include
it in the AST and only exclude it in the export
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...
until now buffersettings were always appended using \n which means the first
value would already be written as "\nVALUE". Not anymore.
Also we finally add an option to parse just the front matter. Still not
efficient as we tokenize the whole org file but i don't think saving a few
milliseconds would be worth making the code uglier.
No need to replace html entities in the result - we can just do it when we
write a text node - the only thing that actually contains text and thus
entities!
- 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
To more faithfully handle inline images we need to know whether the original
link included a description - being more explicit about that will make it
easier.
see org.el/org-display-inline-images
> An inline image is a link which follows either of these
> conventions:
>
> 1. Its path is a file with an extension matching return value
> from `image-file-name-regexp' and it has no contents.
>
> 2. Its description consists in a single link of the previous
> type.
- add return link from footnote definitions -> footnote reference
- wrap footnote definition content in div for easier styling
- class rather than id bc idk consistency
The highlight function from hugo already wraps the highlighted source code in
div > pre > code
e.g.
<div class="highlight">
<pre
style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4">
<code class="language-sh" data-lang="sh">echo hello world</code>
</pre>
</div>
So now we always delegate all that to the highlight function
