[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Org-syntax: Intra-word markup
From: |
Max Nikulin |
Subject: |
Re: Org-syntax: Intra-word markup |
Date: |
Fri, 3 Dec 2021 21:24:05 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
On 03/12/2021 02:03, Nicolas Goaziou wrote:
Denis Maier writes:
As for suggestions: If just using /intra/word creates ambiguities, what
about the asciidoc solution? So //intra//word?
I sympathize to the idea of intra-word emphasis, but the syntax above is
going to cause some ambiguous situations.
I suppose, some more general solution is required.
I do think the marker + zero-width space is one way to go. We could, as
an improvement, consider zero-width spaces around emphasis markers to be
part of the markup, and replace them along during export.
Zero-space characters adjacent to emphasis markers is a better idea than
replacing any zero space. However I agree with Juan Manuel that white
space characters, especially completely invisible (I am not Eli who sees
such special characters by moving cursor through them) should not be
overloaded. From my point of view, it is acceptable to use zero width
spaces as a workaround but they should not become official part of Org
syntax.
Another solution is to introduce a less-subtle, but less prone to
ambiguity, syntax, e.g.,
/{bold}/markup or /|bold|/markup
where /{ }/ or /| |/ become "extended" markers.
More explicit markup leaves less room for ambiguities, and I like the
idea due to this reason. On the other hand it diverges from principle of
lightweight markup. The almost only special character in TeX is "\",
HTML has three ones "&<>" with simple escape rules. Org uses many
special characters to avoid verbosity and requires some tricks to escape
them. Markers like "\{" make Org more verbose but do not make it more
strict, a lot of things still rely on heuristics.
I have an idea what can be done when some special markup is required
that is not fit into current syntax. Unfortunately some new constructs
should be introduced anyway: inline objects and multiline elements that
represent simplified result of parsed Org structures:
((italic "intra") "word")
wrapped with some markup. It should satisfy any special needs (and even
should allow to create invalid impossible constructs). Maybe idea of
combination of lightweight markup and low-level blocks better suits for
some other project with more expressive internal representation. In Org
it may become the most hated feature.
- Re: Org-syntax: Intra-word markup, (continued)
- Re: Org-syntax: Intra-word markup, Russell Adams, 2021/12/05
- Re: Org-syntax: Intra-word markup, Samuel Wales, 2021/12/05
- Re: Org-syntax: Intra-word markup, Nicolas Goaziou, 2021/12/02
- Re: Org-syntax: Intra-word markup, Juan Manuel Macías, 2021/12/02
- Re: Org-syntax: Intra-word markup, Nicolas Goaziou, 2021/12/02
- Re: Org-syntax: Intra-word markup, Juan Manuel Macías, 2021/12/02
- Re: Org-syntax: Intra-word markup,
Max Nikulin <=
- Re: Org-syntax: Intra-word markup, Juan Manuel Macías, 2021/12/03
- Re: Org-syntax: Intra-word markup, Denis Maier, 2021/12/04
- Re: Org-syntax: Intra-word markup, Tom Gillespie, 2021/12/04
- Re: Org-syntax: Intra-word markup, John Kitchin, 2021/12/04
- Re: Org-syntax: Intra-word markup, Juan Manuel Macías, 2021/12/04
- Raw Org AST snippets for "impossible" markup, Max Nikulin, 2021/12/06
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/06
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/06
- Re: Raw Org AST snippets for "impossible" markup, Max Nikulin, 2021/12/08
- Re: Raw Org AST snippets for "impossible" markup, Juan Manuel Macías, 2021/12/08