emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Date: Fri, 28 Jan 2022 06:15:10 +1100	[thread overview]
Message-ID: <87mtjhnfd0.fsf@gmail.com> (raw)
In-Reply-To: <87r18t7fc5.fsf@localhost>

Ihor Radchenko <yantar92@gmail.com> writes:

> Rudolf Adamkovič <salutis@me.com> writes:
>> Let $r_i$ denote the \(i\)-th rotation of $t$ with a suffix of $\ell|t|$
>> characters deleted, for […]
>> Me, if I could, I would pay money for this feature, for it would allow
>> me to use $$ consistently, focusing on mathematics instead of markup
>> idiosyncrasies of "rotation $i$" versus "\(i\)-th rotation".
> Would it improve things for you if we change how \(...\) _looks_ in Org
> buffers?
> The problem with parsing is more than just supporting $i$-th and
> similar. For example, AMS style guide explicitly advises against using
> $i$-th in favour of $i$th [1]:
>     Do not hyphenate “th” expressions: xth, not x-th or xth .
> We can theoretically make a change to support "-", but then it will be
> logical to support $i$th as well. (If we don't some users will still be
> confused after trying to write $i$th and then not getting the expected
> results). In this question, it would make sense to implement
> all-or-everything approach. Otherwise, confusion (like raised in this
> thread) will be inevitable.
> However, from point of view of Org mode parser, supporting $i$th is a
> nightmare.  Remember that Org mode is _not_ LaTeX and we have to support
> a lot more frivolous syntax (even in LaTeX, runaway $ is often a source
> of cryptic compilation errors). Currently, we _must_ rely on heuristics
> to determine $$-style latex fragments. I do not know any way to support
> $$ syntax without creating deviations from LaTeX. Extending the
> heuristics will not resolve the underlying ambiguity of $$ syntax, just
> hide it within even more obscure cases.
> Given the raised concerns, may we solve the issue with too verbose
> \(...\) unambiguous syntax using the following approach:
> 1. Fontify \(...\) replacing the brackets with a single character. For
>    example:
>       \(...\) -> ⁅...⁆
> 2. Provide convenient way to input \(\) brackets through
>    electric-pair-mode or trough org-cdlatex-mode.
> Best,
> Ihor
> [1] https://www.ams.org/publications/authors/AMS-StyleGuide-online.pdf


Just my $0.02 worth -

I think this is the right approach. Retaining support for $..$ doesn't
seem feasible given all the complexities it brings with it. The main
objections to the alternative appear to centre around readability and
inconvenience of having to type additional characters or dealing with
muscle memory use to $...$. These are essentially interface issues and I
think we can largely address them using existing Emacs facilities. This
will reduce the change impact to that sub-set of org users accustomed to
$...$ while bringing the benefit of a cleaner and potentially more
efficient parser to all org users.

If we do deprecate support for $...$, it might also be a good idea to
see if we can add a utility function which would make it easier for
people to migrate existing documents to the new/alternative syntax. For
the same reason it is hard to reliably parse $...$ syntax, we probably
can't automate that transition, but we should be able to reduce the effort
required to update existing documents. 

  reply	other threads:[~2022-01-27 19:39 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 [this message]
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
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=87mtjhnfd0.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \


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