The characters allowed before an opening marker and after a closing one
were a narrower set than org's, so =verbatim=-adjacent did not close and
-=code= did not open.
Both sets now match orgo — the reference the conformance corpus is
generated from — rather than my recollection of the Emacs defaults, which
was wrong in two ways the issue now records: no en or em dashes, and no
\.
- before an opener: whitespace, or
-({'" - after a closer: whitespace, or
-.,;:!?)}["'
] leaves the post set, where org never had it. That looks alarming until
you notice [ is in the set and ] is not — which is consistent, because
a link's description is parsed as its own run, so a closing ] never
actually follows a marker. The test asserts [[url][=code=]] still yields
a verbatim description rather than taking my word for it.
Checking
79 tests green, corpus conformance unchanged at 11/12.
Grepped the org content actually in use — both READMEs and the whole wiki —
for the patterns whose parse changed. Every hit is =--flag=, where the
dash sits inside the body and is governed by the unchanged non-whitespace
rule, not at a boundary. Confirmed by parsing those exact lines: --json,
--scope read, -repos, --limit <n>, and the ssh.mode = "system"
case from 0.3.0 all still come out right.
Closes #1