Laith Bahodi <> writes:

> Hi! I'm working on a parser for org and I noticed something about
> nested markup in the syntax spec: markup starting at the limit of
> another object seems like it shouldn't be interpreted as markup. The
> spec says that the precondition characters are:
>   Either a whitespace character, -, (, {, ', ", or the beginning of a line.
> With links, since `[` isn't in that list, the spec seems to imply the
> following wouldn't contain an italic block, but it does:
> [[][/according to the spec, this shouldn't be marked up/]]
> same goes for  */abc/* (since `*` isn't in the set defined by PRE)

Fair point. We indeed missed this detail in the syntax blueprint.

Does the attached patch clarify things?
>From 974786c726e151ea6bb709bd508faab1cc155fcf Mon Sep 17 00:00:00 2001
Message-Id: <>
From: Ihor Radchenko <>
Date: Thu, 8 Jun 2023 14:08:30 +0300
Subject: [PATCH] * (Special tokens): Clarify recursive matching

Explain that contained objects are only matched against parent

Reported-by: Laith Bahodi <>
--- | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/ b/
index ee05c5a8..7073442b 100644
--- a/
+++ b/
@@ -161,6 +161,13 @@ *** Special tokens
+/PRE/ and /POST/ token are only matched against the contents of the
+containing object. For example, /bold/ object within link description is
+only matched against the description text =*bold* description=, not
+against the full containing link text:
+: [[][*bold* description]]
 *** Case significance
 In this document, unless specified otherwise, case is insignificant.

> Also, how are these objects intended to be handled? I couldn't
> pinpoint where in `org-element` this is approached.

The parser narrows to the contents and starts from there, ignoring all
the surrounding text.  See `narrow-to-region' in

Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <>.
Support Org development at <>,
or support my work at <>

Reply via email to