Max Nikulin <maniku...@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).
