Hi, Ihor,
Ihor Radchenko writes:
> Given the raised objections, zero-width space does not appear to be a
> useful escape symbol because it has its valid uses as a standalone space
> symbol.
>
> The raised objections can be solved using some kind of intricate
> heuristics, but I do not feel like it is a good direction to go. The
> code will be too complex and fragile.
>
> Therefore, I am proposing a different approach for shielding
> fontification: introducing a special entity.
>
> The new entity is \--, which is a valid boundary between emphasis
> markup. It will be removed during export (replaced by "").
>
> "\--" specifically is somewhat arbitrary choice. The actual requirements
> for the entity name are: (1) No clash with LaTeX (which is why simpler
> \- would not cut it); (2) Being a valid markup boundary: entity must end
> with (any space ?- ?\( ?' ?\" ?\{).
>
> I am attaching a tentative patch introducing the new entity. Note that
> some minor tweaks to the parser were needed. I do not see it as a big
> deal - the current entity regexp has much more cumbersome exceptions.
>
> Also, the patch will not work correctly on org → org export, similar to
> pointed in one of the replies to the previous abandoned approach. I do
> not want to address it here because a much more appropriate solution for
> this issue is changing org-element-interpret-data.
>
> Consider (org-element-interpret-data '("asd" (bold () "bold") "bsd"))
> This will return "asd*bold*bsd", which is not correct even though the
> given Org datum is not wrong by itself - such things can easily appear
> when user filters are applied to parse tree during org→org export.
>
> Otherwise, the patch should be good enough to play around and kick-start
> the discussion.
I'm late joining this thread, although I am particularly interested in
the topic.
I can't make any technical comments because I haven't had time to test
the patch yet, but I have to say that your idea of using a special
entity seems to me the best approach to the problem. I would vote for
this to be the way to go.
I believe that using the zero width space character as an escape
character is not a happy idea, and I have already left my arguments in
some other thread, long ago. The zero width space is a random
workaround, but should not (in my opinion) be part of the markup. For
various reasons: it is not an ascii character, there are certain
contexts in which it can produce an unexpected result in LaTeX, etc. In
addition, the zero width space, as an escape character, has a curious
anomaly: it is an escape character that does not have a plan B and a way
to escape the escape character when you want to use it by itself.
I also like the idea of using a special entity because it is not
necessary to invent anything new and it takes advantage of an existing
resource.
Well, that's my opinion.
Best regards,
Juan Manuel
