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...
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
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
I went through the issues of goorgeous and picked a few that seemed easy enough
to add (and added some fore as todos for later). That helped a lot and showed
some bugs / edge cases that required changes.
- the org writer wrote a lot of eol spaces and just removed it whenever
String() was actually called. That worked until now but did not bode with
rendering an empty headline - by removing ALL eol space we would render "* "
back as just "*" -> not a headline anymore.
- the html writer had some special handling for line spacing inside paragraphs
and list items - with the introduction of more blocks we need that handling
everywhere.
As browsers / html renderers are nice enough to collapse whitespace (and
especially collapse "\s*\n" into " ") we can just write out the newlines and
let the renderer take care of the rest.
