Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> +Sometimes, Org mode has difficulties recognising markup. It usually >> +happens when markup marker symbols are present inside verbatim or code >> +blocks: > > I disagree with the wording. Org mode has no difficulties recognizing > markup nor does it parses text incorrectly. This is similar to the well > known surprise: > > #+begin_example > * something > #+end_example > > Here, we are simply fooled by the fontification process. > > Otherwise, the patch looks good to me.
I updated the patch. If you have no objections on the new wording, I will push it to main. >> + ;; Verify that we are at the right object. >> + (let ((object (save-excursion >> + (save-match-data >> + (goto-char (match-beginning 2)) >> + (org-element-context))))) >> + (and (memq (org-element-type object) >> + '(bold italic verbatim code strike-through)) >> + (eq (match-beginning 2) >> + (org-element-property :begin object)))))) > > I sympathize with the idea. As long as fontification does not rely on > the parser, we will face issues like the one at stake. So, ultimately, > Org will hopefully move in that direction. > > However, I'm not convinced making such local changes is going to help us > in the long run. It may be more fruitful to think this evolution > globally, as it involves a fair bit of rewriting of the fontification > process. For example, it may only be necessary to parse the part of the > Org document being fontified only once, and then apply all fontification > functions to the resulting tree rather than have each of them calling > the parser, like the above. > > In any case, I think fontification deserves a dedicated thread, in > addition to some love. Ok. I will create a new discussion thread on fontification. Best, Ihor
>From a1a497a80578669ef1e96700aa592aadd8d0d7ec Mon Sep 17 00:00:00 2001 Message-Id: <a1a497a80578669ef1e96700aa592aadd8d0d7ec.1637329857.git.yanta...@gmail.com> From: Ihor Radchenko <yanta...@gmail.com> Date: Fri, 19 Nov 2021 19:27:56 +0800 Subject: [PATCH] org-manual.org: Clarify how to handle markup ambiguity * doc/org-manual.org (Emphasis and Monospace): Advice users to insert zero width space when Org does not parse emphasized text correctly. --- doc/org-manual.org | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/doc/org-manual.org b/doc/org-manual.org index a38dbec4a..9615209a1 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -10818,6 +10818,17 @@ ** Emphasis and Monospace ~org-fontify-emphasized-text~ to ~nil~. To narrow down the list of available markup syntax, you can customize ~org-emphasis-alist~. +=*=, =/=, =_=, ===, and =~= symbols inside =verbatim= or ~code~ can +sometimes produce unexpected markup. For example, + +#+begin_example +/The whole line is supposed to be marked italic, but the following +~user/?variable~ contains italics =/= marker and confuses Org parser/. +#+end_example + +You can use zero width space to help Org sorting out the ambiguity. +See [[*Escape Character]] for more details. + ** Subscripts and Superscripts :PROPERTIES: :DESCRIPTION: Simple syntax for raising/lowering text. -- 2.32.0