On 04/01/2022 22:06, Juan Manuel Macías wrote:
Max Nikulin writes:

Ideally it should be done pandoc and only if it causes incorrect
parsing of org markup. NBSP, probably, should be replaced by some
exporters, I do not think, it is a problem e.g. in HTML files.

The reason for this filter is my own comfort. Linguistics texts contains
a lot of certain characters such as "/" or "*", and they are often
italicized or bold. So, in order not to be more confused than necessary,
I prefer that they pass as entities.

It seems, lightweight markup is more annoyance than advantage for you. Tom posted some thoughts on more rigorous syntax in the following message:

Tom Gillespie. Re: Org-syntax: Intra-word markup.
Sat, 4 Dec 2021 09:53:11 -0800.
https://list.orgmode.org/ca+g3_pnca3hy6tudpmfhgt35amj9a-y8dbnqo+zvbov6y3n...@mail.gmail.com

For C and C++ it is possible to tune some aspects of compiler behavior using

    #pragma something

directives. In some cases it might be convenient to e.g. temporary disable emphasis markers (or switch to more verbose alternative) through

    #+some: keyword

In general, there are certain
characters that I am more comfortable working with as entities than as
literal characters (for example, a lot of zero-width combining
diacritics that are used a lot in linguistics or epigraphy (and there
are no fonts that include the NFC normalized version of all possible
combinations: in fact, they are not in Unicode, and would have to go to
the private use area). Summarizing, I prefer that these characters have
their actual typographic representation only with LuaTeX. A very typical
example is the character U+0323 (COMBINING DOT BELOW). It is very
uncomfortable to work /in situ/, although there are fonts that usually
render it well (with the 'mark' otf tag).

I have seen warnings concerning complications due to variants of character representation, but I have no experience such nuances (either typing and editing or processing text programmatically). Dagger and non-breaking space in your code snippet were much more simpler cases.


Reply via email to