Rudolf Adamkovič <salu...@me.com> writes:
> João Pedro de Amorim Paula <jpedrodeamo...@gmail.com> writes: > >> On 01 February 2022 22:00, Rudolf Adamkovič <salu...@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.
