The actual parameter parsing logic in emacs org mode is quite complex [1]. All
we want for now is to handle parameter values containing spaces [2]. Splitting
on ` :` gets us close enough for now. As I'm very opposed to copying 100 lines
of parameter parsing logic just to get exports right let's wait for use cases -
no hurt in gathering requirements as we go.
[1] https://github.com/bzg/org-mode/blob/master/lisp/ob-core.el#L1481
[2] I never ran into such parameters before and wrongly assumed that splitting
on spaces would be enough. boy was i wrong - just look at that massive
function [1]! that's why we can't have nice things!
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.
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.
- drawer entries without value were printed as FOO rather than :FOO:
- account for differences between raw & non-raw block:
raw blocks are not wrapped in a further element, just raw text & line breaks:
-> the first line has to be indented manually
non raw blocks do not end in a linebreak newline -> the END_BLOCK line has to
be indented (rather they end with a manual newline from another element)
list items only contain content that is indented to their respective
level. Except when that content is inside a block. To allow for this we have to
ignore the parentStop when parsing a block and just include everything until
the end of that block.
Can't think of any problems with this right now. Let's see if this comes
back to bite me.
Until now we expected the .org file to print back to itself - we can't do that
when the input is not pretty printed already - with the introduction of blocks
with unindented content that will be the case.
