- 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.
org mode supports [1] setting the value attribute [2] of ordered list items to
change the numbering for the current and following items. Let's do the same. As
the attribute has no meaning for other types of lists [2] we'll just not
support it for those cases [3].
[1] https://orgmode.org/manual/Plain-Lists.html#Plain-Lists
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/li#attributes
[3]
Org mode seems to instead set the id attribute for e.g. unordered lists
starting with `[@\d+]\s` - but I don't really see the value in that and will
skip that for now.
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!
This reverts commit bf7f957af2.
We still have to manually install it for now but we don't have to fuck around
with env vars anymore. github actions still defaults to go 1.15 [1]. Whatever.
[1]
```
ls -lisah $(which go)
108022 0 lrwxrwxrwx 1 root root 42 Mar 18 22:15 /usr/bin/go ->
/opt/hostedtoolcache/go/1.15.10/x64/bin/go
```
org mode allows rendering the toc anywhere in the html document using the `TOC`
keyword [1]. There's more options but `#+TOC: headlines $n` should be enough
for starters. Note that org mode still requires setting `#+OPTIONS: toc:nil` to
disable the default toc
[1] https://orgmode.org/manual/Table-of-Contents.html
Hugo defaults to serving files with pretty urls [1] - this means
`/posts/foo.org` is served at `/posts/foo/`. This works because servers
default to serving index.html when a directory is specified and hugo renders
the post to `/posts/foo/index.html` instead of `/posts/foo.html`. To make
relative links work we need to (1) remove the fake `foo/` subdirectory from
unrooted links and (2) replace any `.org` suffix with `/`.
[1] https://gohugo.io/content-management/urls/#pretty-urls
As headlines are always lvl (indent) 0 I thought it would be clever to abuse
the lvl field to store the headline lvl. Well, here we are - it wasn't clever.
List items only end when their parent ends or they run into something that's
not indented enough - everything else becomes part of the list item. Abusing
the token.lvl field (indent) for the headline lvl means headlines look indented
to the list item parsing logic - i.e. they become part of the list item if the
headline has a high enough lvl. That should never happen - so let's get rid of
the hack and (re-)calculate the headline lvl when we need it.
Turns out Org mode supports image links natively and we don't have to go out of
spec!
From https://orgmode.org/manual/Images-in-HTML-export.html:
[...] if the description part of the Org link is itself another link, such as
‘file:’ or ‘http:’ URL pointing to an image, the HTML export back-end in-lines
this image and links to [...]
html does not support table separator rows as Org mode does. Emacs org export
simulates rows as defined by separators by wrapping all the rows between 2
separators into a separate tbody. The html spec is fine with that [0] so we
follow.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tbody
All tags are put on a line by themselves to help with visual
diffing. Apparently this extra cosmetic whitespace causes problems inside p
tags for ppl who want to use `white-space: pre`. Not much hurt for visual
diffing in removing cosmetic whitespace for just p tags and can't think of
anything that would break because of this right now. So let's do it and wait
for things to break.
if we define a custom LINK for file we run into index problems bc it's trimmed
before already - this fixes that. Shouldn't ever happen but whatever, fuzzing
found it.
