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