Re: On zero width spaces and Org syntax

[Tim Cross]

Max Nikulin <manikulin@gmail.com> writes:

> On 04/12/2021 04:48, Tim Cross wrote:
>> My vote is to simply maintain the status quo. Don't modify the syntax,
>> don't make the zero space character somewhat special or processed in any
>> special way during export. In short, accept that inner word markup has
>> only limited support and if that is a requirement which is critical to
>> your use case, accept that org mode may not be the right solution for
>> your requirements.
>
> Tim, you are skeptical concerning usage of Org markup outside of Emacs. Though
> some subscribers of this list support such idea with hope for collaboration 
> with
> colleagues and for other reasons. Status quo in respect to similar questions
> increases risk that other tools will adapt different workarounds and
> incompatible dialects will appear.

This is a misrepresentation of my position. I've never stated I'm
sceptical or org markup outside of Emacs. I'm sceptical of org mode
outside of Emacs, but have never expressed an opinion of org markup
outside of Emacs.  

However, I will now....

Org markup outside Emacs is very much a secondary concern that would be
a nice to have for some workflows, but should be achieved with zero
impact on Emacs users. Org mode and the markup it uses is primarily an
Emacs mode. In fact, making it easier for non-Emacs users to use org
mode is almost certainly working against the FSF philosophy. I'm pretty
certain RMS would be very unhappy of any efforts to allow users to use
org mode in products like MS Visual Code. While it is fine for 3rd party
systems to try and mimic org mode, it is totally contrary to GNU
philosophy for a GNU project to actively support or enable such
functionality in non-free solutions. Any decisions to make changes to
org mode must be primarily for the benefit of Emacs users. When such
decisions also have benefit for non-Emacs users, that is great, but it
should not be a driving factor in making decisions regarding change or
extensions to org mode.

>
> From the point of view of popularizing Org it is better to make some decision:
> either zero-width space should become a part of syntax or some other printable
> marker should be chosen to suppress effect of Org markup or vice versa to
> activate some construct.

Chasing popularity is always a mistake and should never be used as an
argument for change. We are also talking about something where there is
little evidence of demand. We have a single post from someone asking how
to support inner word emphasis and suddenly, threads about modifying
syntax, modifying back ends and a dozen proposals on how to support this
'feature'.

A question I would ask is that if extending and adding broader support
for emphasis is so straight-forward, why do we already have so many
issues reported about incorrect application of markup? We have not been
successful in eliminating existing ambiguities with the markup and yet
some would have us charge off and add even more complexity.

Rather than extending markup syntax, lets focus on fixing the real issues we
already have. There have been far more posts to this list about that
than about inner word emphasis. For example, the many posts about markup
and links. 

With respect to the status of zero width space, I'm not convinced we
need to do anything. Would it be classified as a kludge, probably. Does
it provide an escape hatch for some situations, yes. Does that mean it
needs to be formally recognised and added to the syntax, no. Does the
existence of this kludge make implementation of org mode markup for
other tools more difficult or less clear, probably. Should that be a
primary concern for Emacs org-mode, no. Should it be something we
consider when making decisions, sure, but only as a secondary
consideration. 

What the need for the zero width space kludge really means is that in
some situations, we have some ambiguity in the existing syntax. Can we
fix those ambiguities? I don't know - so far, I've not seen a proposal
which doesn't introduce as many problems as it solves, (though Tomp's @@
proposal looks interesting, but lots more analysis is required).

The zero width kludge is certainly a symptom of limitations in the
existing syntax definition. However, I don't think it is the cure and I
don't agree it needs to be formally recognised as part of the syntax -
it is not the cure. If we can find the correct cure, the zero width
kludge will not be necessary (or will only be necessary in extreme and
rare edge cases).