Re: Parsing nested markup objects

[Ihor Radchenko]

Ihor Radchenko  writes:

> 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: 
> <974786c726e151ea6bb709bd508faab1cc155fcf.1686222568.git.yanta...@posteo.net>
> From: Ihor Radchenko 
> Date: Thu, 8 Jun 2023 14:08:30 +0300
> Subject: [PATCH] * org-syntax.org (Special tokens): Clarify recursive matching

Applied, onto master.
https://git.sr.ht/~bzg/worg/commit/7b98eb36

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

Re: Parsing nested markup objects

[Ihor Radchenko]

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:
>
> PRE MARKER ...
> PRE
>   Either a whitespace character, -, (, {, ', ", or the beginning of a line.
> https://orgmode.org/worg/dev/org-syntax-edited.html#Emphasis_Markers
>
> With links, since `[` isn't in that list, the spec seems to imply the
> following wouldn't contain an italic block, but it does:
>
> [[https://example.com][/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: <974786c726e151ea6bb709bd508faab1cc155fcf.1686222568.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 8 Jun 2023 14:08:30 +0300
Subject: [PATCH] * org-syntax.org (Special tokens): Clarify recursive matching

Explain that contained objects are only matched against parent
contents.

Reported-by: Laith Bahodi 
Link: https://orgmode.org/list/CABhQr0TRuGeJMn+G5xzqJuX=uhvwibhjr1+p8qqdrha8kup...@mail.gmail.com
---
 org-syntax.org | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/org-syntax.org b/org-syntax.org
index ee05c5a8..7073442b 100644
--- a/org-syntax.org
+++ b/org-syntax.org
@@ -161,6 +161,13 @@ *** Special tokens
 PRE TOKEN POST
 #+end_example
 
+/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:
+
+: [[https://orgmode.org][*bold* description]]
+
 *** Case significance
 
 In this document, unless specified otherwise, case is insignificant.
-- 
2.40.0


> 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
`org-element--parse-objects'.

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

Re: Parsing nested markup objects

[Ihor Radchenko]

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:
>
> PRE MARKER ...
> PRE
>   Either a whitespace character, -, (, {, ', ", or the beginning of a line.
> https://orgmode.org/worg/dev/org-syntax-edited.html#Emphasis_Markers
>
> With links, since `[` isn't in that list, the spec seems to imply the
> following wouldn't contain an italic block, but it does:
>
> [[https://example.com][/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: <974786c726e151ea6bb709bd508faab1cc155fcf.1686222568.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Thu, 8 Jun 2023 14:08:30 +0300
Subject: [PATCH] * org-syntax.org (Special tokens): Clarify recursive matching

Explain that contained objects are only matched against parent
contents.

Reported-by: Laith Bahodi 
Link: https://orgmode.org/list/CABhQr0TRuGeJMn+G5xzqJuX=uhvwibhjr1+p8qqdrha8kup...@mail.gmail.com
---
 org-syntax.org | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/org-syntax.org b/org-syntax.org
index ee05c5a8..7073442b 100644
--- a/org-syntax.org
+++ b/org-syntax.org
@@ -161,6 +161,13 @@ *** Special tokens
 PRE TOKEN POST
 #+end_example
 
+/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:
+
+: [[https://orgmode.org][*bold* description]]
+
 *** Case significance
 
 In this document, unless specified otherwise, case is insignificant.
-- 
2.40.0


> 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
`org-element--parse-objects'.

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