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.
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 [...]
delimiters are not always 2 in length - $ being the exception. Also we have to
make sure to handle both $ and $$ delimiters.
Not proud of this solution but can't think of anything simpler right now - will
come back to this later hopefully.
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.
fuzzed index out of range and moved range check into for condition as \\
followed by spaces at the end of the inline text should not be turned into an
ExplicitLineBreak (just like \\ not followed by spaces).
- Remove unused footnote section title option
- Move away from maintaining a list of footnotes in the document (only needed
for html export, potential maintainance overhead when modifying the document)
and rather only build it on export when required.
- HTML export: Rename all footnotes to numbers (so we can support anonymous
footnote references by assigning them a number) and export footnotes in order
of reference, not definition. The implementation of this makes it natural to
also stop exporting unused footnote definitions so we do that as well.
It's possible for the input to end right after the explicit line break,
i.e. after the second \. This currently leads to an out of range index into
input (as the for loop starts with start+2 and [start:start+1] is the \\).
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.
- 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
The regexps are meant to extract a match immediately following the cursor - the
anchor should have been there from the beginning...
Also empty sub/superscript doesn't make sense - nested sub/superscript does
make sense but yagni.
- 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
Org mode does not care where those tokens are when it comes to the
export (afaict). We'll do the same.
(They should only be in the first line of a list item or a headline)
While adding another test case from the goorgeous issues it became clear that
inline markup and html entity replacement were erronously applied to raw text
elements like inline code =foo=, src/example/export blocks, example lines,
etc.
To correctly handle those cases in both org and html exports a new
parseRawInline method had to be added.
Also some misc html export whitespace fixes and stuff
To more faithfully handle inline images we need to know whether the original
link included a description - being more explicit about that will make it
easier.
see org.el/org-display-inline-images
> An inline image is a link which follows either of these
> conventions:
>
> 1. Its path is a file with an extension matching return value
> from `image-file-name-regexp' and it has no contents.
>
> 2. Its description consists in a single link of the previous
> type.
