... 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
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.
