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.
Instead of the bare bones default config we embedded as a string until now we
can use go 1.16 embed to embed the test blorg.org which makes a much better
starting config (if only to see what's possible).
hugo is nice - but it's huge. I've never built a static site generator before
and thought the world could use one more - it's not like there's already enough
choice out there!
No, but seriously. I love hugo and it has all the bells and whistles and you
should definitely use that and not this. I just like reinventing the wheel to
learn about stuff - and I like the 80/20 rule. This gives like 60% of what I
want already and is tiny fraction of hugo in terms of LOC (hugo without it's
bazillion dependencies is like 80k+ - this is like 500 and very likely won't
ever grow above let's say 5k).
Also org mode is awesome and why not use it as a configuration format as
well. Let's see where this goes. YOLO.
