Re: [PATCH] Re: c47b535bb origin/main org-element: Remove dependency on ‘org-emphasis-regexp-components’

[Ihor Radchenko <yantar92@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2046 bytes --]

Nicolas Goaziou <mail@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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-manual.org-Clarify-how-to-handle-markup-ambiguit.patch --]
[-- Type: text/x-diff, Size: 1379 bytes --]

From a1a497a80578669ef1e96700aa592aadd8d0d7ec Mon Sep 17 00:00:00 2001
Message-Id: <a1a497a80578669ef1e96700aa592aadd8d0d7ec.1637329857.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@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