emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Sébastien Miquel" <sebastien.miquel@posteo.eu>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: "Rudolf Adamkovič" <salutis@me.com>,
	emacs-orgmode <emacs-orgmode@gnu.org>,
	"Eric S Fraga" <e.fraga@ucl.ac.uk>
Subject: Re: [PATCH] Add support for $…$ latex fragments followed by a dash
Date: Thu, 27 Jan 2022 19:34:24 +0000	[thread overview]
Message-ID: <da626035-972a-f3f5-6bd8-5a8a3918a071@posteo.eu> (raw)
In-Reply-To: <87r18t7fc5.fsf@localhost>


Ihor Radchenko writes:
> 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).

I disagree.
  1. The $…$- pattern is also used for other common constructions, such
     as $n$-dimensional, $K$-lipschitz, etc. As for $n$−th vs $n$th, both
     are commonly used. In french, $n$− is the correct one.
  2. It does not logically follow that we should support $i$th as well,
     since, as you point out, it'd be impossible. One argument for the
     patch is that is it very simple.
  3. The $n$th construction failing is not as confusing. One
     understands quickly what the limitation is, and several
     workarounds are available, whereas there's no good reason for the
     $n$− limitation, and it's harder to think of a workaround.

I should mention that the zero-width space character can be used to
work around both limitations.

> 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.
If the $…$ syntax were to be deprecated, this would be a nice
addition, indeed. As a user, I find it quite satisfactory (with some
added utility to easily switch between the \(…\) and \[…\] syntax).
Some possible drawbacks :
  - are the display hacks scalable in a large document, with many LaTeX
    snippets ?
  - this feature may still be hard to discover, turn on and use by
    users more concerned with mathematical content and less familiar
    with emacs features such as fontification, automatic insertion of
    complex delimiters and whatnot.
  - hiding the syntax feels a bit weird, although it is already
    done with emphasis markers.

With respect to the possible deprecation of the $…$ syntax, the
drawbacks and complexity of this alternative should be weighted
against those of the current $…$ syntax, but no one has really spelled
out what the latter are. We're trading complexity here for complexity
there, fixing the false positives (but how common are they ?) and the
false negatives (which can be an annoyance while writing a snippet).

Thank you for bringing this up,


Sébastien Miquel

  parent reply	other threads:[~2022-01-27 19:37 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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=da626035-972a-f3f5-6bd8-5a8a3918a071@posteo.eu \
    --to=sebastien.miquel@posteo.eu \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=salutis@me.com \
    --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).