The existing approach made it hard to extend existing writers.
With this change, replacing individual methods of a writer is possible by
embedding it.
Sharing the WriteNodes function also removes some unnecesseray duplication, so
win win.
Unlike the other BufferSettings, #+OPTIONS: specifies multiple options and we
cannot just look it up in either BufferSettings or DefaultSettings - both have
to be checked
Leftover from the days before BufferSettings & DefaultSettings - now that those
exists the status keywords are actually defined in
- DefaultSettings["TODO"] for the default
- BufferSettings["TODO"] for any customizations
Also ! i < len => i >= len because it's easier on the eyes
- 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
- enable logging by default: debug was a bad name - it's error logging that I
just want to hide in tests
- don't panic (all the time)
- use a logger. this allows us to add more information - like the path of the
parsed file!
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.
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.
