- we can use type casting to check for type instead of adding a dependency on
reflect
- lint complains about redundant types, so get rid of that for peace of mind
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.
Allows consumers to specify `TopLevelHLevel` to `HTMLWriter`, which
works identically to Org's official [`:html-toplevel-hlevel` /
`org-html-toplevel-hlevel`](https://orgmode.org/manual/Publishing-options.html) property.
Fixes#94.
current support for latex fragments was inline only, i.e. lines containing block
elements (e.g. a line starting with `* `, i.e. a headline) will not be parsed
as part of the latex fragment but the respective block element. Parsing latex
blocks at the block level should fix that. Note that in any case we don't do
any processing and just emit the raw latex (leaving the rendering to e.g. js).
Post chars are defined in (nth 1 org-emphasis-regexp-components) in emacs org.
When I initially adapted the list of chars for go, I failed to check how it's
actually used (further down in org.el):
(string-match (concat "[" (nth 1 erc) "\n]") (char-to-string (char-after (point))))
Due to the surrounding [] the `\\` in
'("-[:space:]('\"{" "-[:space:].,:!?;'\")}\\[" "[:space:]" "." 1)
is actually a literal backslash, not an escape of the opening bracket I
guess. I'm not in the mood for thinking any harder about this, so let's hope
this is right. yolo.
Before this commit, if an org document was titled "Title here", the
first line of HTML output would be as follows:
<h1 class="title"><p>Title here\n</p></h1>
This commit changes the HTML writer to instead output the following:
<h1 class="title">Title Here</h1>
I conversatively modified the code, so there might be more cases where
elements should be omitted from the title.
Until now we're not using t.Run to create a sub test for each fixture - for the
current bug I want to only run a single file as I'm a print debugger and don't
care for the noise of logs from other tests. While at it, it made sense to
merge the implementations.
`go mod tidy` kept including goorgeous and blackfriday for me - turns out go
does not honor gitignore [1] and the correct way of ignoring a subdirectory is to
place an empty `go.mod` file in it [2]. As I haven't looked in that file for
quite some time and goorgeous has been deprecated let's rather just get rid of
the comparison altogether.
[1] the .go file requiring goorgeous was placed into `docs/`
when running `make generate-gh-pages`. `docs/` is gitignored but not
ignored by go
[2] https://github.com/golang/go/wiki/Modules#can-an-additional-gomod-exclude-unnecessary-content-do-modules-have-the-equivalent-of-a-gitignore-file
go 1.18 embeds vcs info into binaries by default [1] allowing us to provide a
rudimentary version cmd in just a few lines. (version) vcs tags are not
embedded for now - just the commit hash should be good enough for now though.
[1] https://tip.golang.org/doc/go1.18
seems like i removed that target at some point and forgot to update the
readme. As installing go is os specific let's just check for go instead and
let the user handle the installing.
