Re: [PATCH] Add support for $…$ latex fragments followed by a dash

[Tim Cross <theophilusx@gmail.com>]

Rudolf Adamkovič <salutis@me.com> writes:

> João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> writes:
>
>> On 01 February 2022 22:00, Rudolf Adamkovič <salutis@me.com> wrote:
>>
>>> Me, I cannot use any of these "pretty" features because, simply put,
>>> they break plain text.  For example, they cause misaligned tables and
>>> make the text overflow the fill column, which I keep at 72 columns.
>>
>> […] there are fonts that enforce Unicode (all characters, from what I
>> understand, Unicode included) characters to be exactly 1 unit width,
>> i.e. Unicode characters are the same widths as other characters.  At
>> least I can guarantee that any of the Term (all characters are the
>> same length, but has ligatures) or Fixed (same as Term but no
>> ligatures) for Iosekva [1] have this given property.
>>
>> [1] https://typeof.net/Iosevka/
>
> Thank you for sharing!  I use the amazing "Hack" typeface [1].  Then, I
> fail to understand how the font changes the fact that Org breaks "the
> promise of plain text" in this regard.
>
> For example, Org can hide its emphasis markers.  Later, one opens the
> file in another editor and sees the truth.  The lines go over the fill
> column, the tables have misaligned columns, and so on.
>

The promise of plain text has no inherent promise regarding alignment,
line wrapping etc. The promise of plain text is simply that - a promise
that org files will be just plain text rather than some application
specific format like many other systems (MS Word, LibreOffice, etc).
Provided you can still edit the file with a plain text editor, org has
not broken its promise.

Ironically, it is this plain text basis of org files which makes
on-going support of $..$ (and any extension) so problematic. Without
this restriction, org files could have a format where elements were
'tagged' to remove ambiguity and simplify the parsing process. However,
this would of course mean that either you had to edit the file within
org mode or you would have to be intimately familiar with the internal
structure of org mode files and use an editor which made
editing/updating the internal structure possible. To be very clear, I am
NOT advocating that org should adopt some form of internal tagging or
structure. I'm only attempting to highlight that having a system which
aims to maintain the data source in plain text comes at a cost.

In LaTex et. al. $..$ works well because $ is a special character. If
you want a literal $, you have to escape it. In org, $ is not a special
character. This means we need complex regular expressions in order to
identify when $ is being used for LaTex specific markup and when it is
being used in other contexts (e.g. literal $ sign, variable name). These
regular expressions are difficult to get right, error prone and above
all, incur a significant performance hit. Extending the syntax further
to support $..$- simply makes the situation worse by adding further
complexity.

So far, all the arguments against removal of support for $..$ are based
on inconvenience and reduced readability associated with the
alternatives. Both legitimate concerns. For many, the proposed change
may seem to be just inconvenient change for no real purpose because they
don't deal with the complexities inherent in making $..$ work and for
others, change is something they would always prefer to avoid.

In this instance, I feel we really need to listen to those who put in
such a dedicated effort in maintaining org mode and accept their
position that sustaining $..$ syntax going forward is problematic and
focus on what can be done to mitigate the impact from this change, make
the alternative syntax more convenient and address the readability
issues.