Since writers are normally only used synchronously (i.e. to write one document
at a time), we don't guard modifications to their internal
state (e.g. temporarily replacing the string.Builder in WriteNodesAsString)
against race conditions.
The package global `orgWriter` and corresponding use cases of it (`org.String`,
`$node.String`) break that pattern - the writer is potentially used from
multiple go routines at the same time. This results in race conditions that
manifest as error messages like e.g.
could not write output: runtime error: invalid memory address or nil pointer dereference. Using unrendered content.
Additionally, since we catch panics in `Document.Write`, the corresponding
stack trace is lost and dependents of go-org never know what hit them.
As using a writer across simultaneously across go routines is not a standard
pattern, we'll sync the use of the global `orgWriter` instead of trying to make
the actual writer threadsafe; less code noise for the common use case.
WriteNodesAsString is simple enough to implement but exposing it is helpful in
the implementation of extending writers and we don't aim to keep writer a small
interface so let's expose it.
Being able to very easily get the original [1] Org mode content seems like
something that will come up quite often and is very little code.
[1] it's not really the original content, but rather the pretty printed version
of that - as the semantics don't change it shouldn't matter.
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
- we can't just look at the len of the string (~ #bytes) - that breaks down for
tables containing characters consisting of multiple bytes. This handles
more (still not all) cases and is good enough for now
- add _ to allowed tag chars - also require space between headline and tags
- links (link itself, not the description) spanning multiple lines are not
supported - otherwise we would have to take care of splitting link and adding
indentation for org pretty printing - and that sounds like such an edge case
that it seems cleaner to forbid them
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...
