From: Tim Cross <email@example.com> To: "Rudolf Adamkovič" <firstname.lastname@example.org> Cc: "João Pedro de Amorim Paula" <email@example.com>, "Sébastien Miquel" <firstname.lastname@example.org>, email@example.com, "Ihor Radchenko" <firstname.lastname@example.org>, "Eric S Fraga" <email@example.com> Subject: Re: [PATCH] Add support for $…$ latex fragments followed by a dash Date: Mon, 07 Feb 2022 11:00:08 +1100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Rudolf Adamkovič <firstname.lastname@example.org> writes: > João Pedro de Amorim Paula <email@example.com> writes: > >> On 01 February 2022 22:00, Rudolf Adamkovič <firstname.lastname@example.org> 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  have this given property. >> >>  https://typeof.net/Iosevka/ > > Thank you for sharing! I use the amazing "Hack" typeface . 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.
next prev parent reply other threads:[~2022-02-07 1:03 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-24 16:42 Sébastien Miquel 2022-01-25 7:56 ` Eric S Fraga 2022-01-25 10:32 ` Sébastien Miquel 2022-01-26 17:15 ` Rudolf Adamkovič 2022-01-27 8:28 ` Ihor Radchenko 2022-01-27 19:15 ` Tim Cross 2022-01-28 14:37 ` Max Nikulin 2022-01-28 16:37 ` Timothy 2022-01-30 15:28 ` Max Nikulin 2022-02-01 14:26 ` Max Nikulin 2022-01-27 19:34 ` Sébastien Miquel 2022-02-01 21:00 ` Rudolf Adamkovič 2022-02-02 2:48 ` João Pedro de Amorim Paula 2022-02-06 19:45 ` Rudolf Adamkovič 2022-02-07 0:00 ` Tim Cross [this message] 2022-01-26 6:33 ` Tom Gillespie 2022-01-26 17:49 ` Sébastien Miquel 2022-01-26 21:49 ` Tom Gillespie 2022-01-27 19:11 ` Sébastien Miquel 2022-01-25 18:09 Goran Zuzic 2022-01-27 18:54 autofrettage
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] Add support for $…$ latex fragments followed by a dash' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).