emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: "Rudolf Adamkovič" <salutis@me.com>
Cc: "João Pedro de Amorim Paula" <jpedrodeamorim@gmail.com>,
	"Sébastien Miquel" <sebastien.miquel@posteo.eu>,
	emacs-orgmode@gnu.org, "Ihor Radchenko" <yantar92@gmail.com>,
	"Eric S Fraga" <e.fraga@ucl.ac.uk>
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: <87tudb4hip.fsf@gmail.com> (raw)
In-Reply-To: <m2zgn3rd7d.fsf@me.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

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

  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 [PATCH] Add support for $…$ latex fragments followed by a dash 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:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tudb4hip.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=jpedrodeamorim@gmail.com \
    --cc=salutis@me.com \
    --cc=sebastien.miquel@posteo.eu \
    --cc=yantar92@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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).