Max Nikulin <manikulin@gmail.com> writes:

> These regexps will always fail under some conditions, since it is not 
> strict markup. An example is emphasis terminated inside link target
>
> /A link [[https://orgmode.org/?oops=true][Org Mode]]

Your example actually reveals a much bigger issue with current element
parser. Even though the link is fontified by Org, if you run
org-element-context on the link, it will return nil. The parsed sentence
will look like:

<begin italic>/A link [[https://orgmode.org/<end italic><begin ordinary
text - it is not a link!>?oops=true][Org Mode]]<end of ordinary text>

The reason behind is partially regexps used to detect emphasised text
and partially the way our parser works - no intersected objects are
allowed.

My intuition says that the current parser behaviour is not correct. It
would make more sense to prioritise link over italics. However, it would
require a major change in the parser - instead of a single pass, the
parser may parse different types of objects sequentially. The emphasis
objects should come last avoiding the markers to have different parents.

Nicolas, WDYT?

>> Maybe something like the attached?
>
> Thank you, Ihor. Another reason why I have not tried to do it myself is 
> that it is necessary to test behavior for users who customized markers. 
> The change should not be fatal for them. I have not checked it with you 
> patch yet.
>
> I was considering some way to warn users if improper customization is 
> detected (unexpected marker is noticed). It should be noticeable to make 
> user aware of export issues but not too annoying.
>
>> +The characters in the alist must not be changed.  They do not affect
>> +the actual Org syntax, just fontification.
>
> Since this is known point of abuses, maybe stronger words are appropriate.
>
> Do not change makers and do not add new ones to use custom markers for 
> existing styles or to introduce new styles. Org syntax is not meant to 
> be configurable and such modifications will not work with export. If you 
> are interested in fontification of custom markup inside Emacs only, 
> there are other ways to achieve desired effect.
> ...
> In addition, I do not like the following phrase in the manual:
>
>> To narrow down the list of available markup syntax, you can customize org-emphasis-alist.

I updated the patch dropping your last suggested sentence in the
docstring. I find it not very helpful for the user. We should either say
nothing (as in the patch) or give a concrete reference how to "achieve
the desired effect".

Best,
Ihor