emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tom Gillespie <tgbugs@gmail.com>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Don't fill displayed equations
Date: Sun, 3 Oct 2021 22:57:23 -0700	[thread overview]
Message-ID: <CA+G3_POJoVK0fWrMCHzLTNkogfwRHP47p=FWSt3i4edzyvgkRg@mail.gmail.com> (raw)
In-Reply-To: <sjc69c$qdk$1@ciao.gmane.io>

Some thoughts.

> Maybe you are right and Tom was actually assuming \begin{equation*}, not
> #+begin_export latex.

Correct. My bad on that one.

> Just as Timothy, I believe that \begin{equation*} is unnecessary verbose
> when \[ works *mostly* in a similar way.

\begin{equation*} is absolutely required if you want to be able to include
newlines because \[ and \begin are not similar at all as far as parsing
is concerned.

From the spec: https://orgmode.org/worg/dev/org-syntax.html#LaTeX_Environments
> CONTENTS can contain anything but the “\end{NAME}” string.
The spec is not completely accurate since latex environments can't
contain a new heading, but the point is that latex environments are
elements, whereas \[ \] is an object.

> If I understand correctly, making \[ \] available outside paragraph
> would mean that it becomes a new element (currently \[\] is a
> latex-fragment object).

Correct. Promoting \[ to an element would mean every \ in an org file
becomes a stop word. Also, Since full fledged latex environments
already exist to serve this purpose I find it hard to justify, especially
given that Org tries to give clear indication of when a block structure
is starting and ending.

> Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
> and \begin{env} ... \end{env} and constructs in Org to be consistent
> with LaTeX?

For \begin and \end yes. For the others no. In general it would be to
make it possible to express things using latex-like syntax that would
otherwise require Org to come up with some new and different syntax.
These are values that may be translated to latex, but they exist inside
a larger syntax that is decidedly not latex, and thus they only have
meaningful translation to latex if they exist as well formed Org.

As a side note, the $ syntax is slated to be deprecated and removed.
https://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments
> It would introduce incompatibilities with previous Org versions, but
> support for $...$ (and for symmetry, $$...$$) constructs ought to be removed.

> Indeed, it will be a breaking change.

I'm actually fairly certain that such a change should never be made
due to the recent changes in org link syntax. Specifically given how
\[ is used for escapes in links. https://orgmode.org/manual/Link-Format.html
This means that the only place you could reliably use \[ is at the start of a
new line preceded only by whitespace. However, if this were to happen then
pretty much every org document that uses \[ \] is at risk for being broken
because something that was once a single paragraph will now be multiple
paragraphs.

If you need multiline use \begin \end, that is what they are there for, and they
fit better with org's general extensible approach to blocks. I would dearly love
to be able to have a single shorthand for src blocks that worked inline and
standalone, but the complexity that it would induce is just not worth it. Same
thing for \[ \]. It seems simple until you get down to account for all the edge
that it would induce in the grammar.

Consider the case where you have something like

\[ something something

more content
more content [[www.example.com/\]oops][evil link]] \]

I've seen enough cases that are similar to this in the existing implementation
that have inconsistent behavior that I can safely say that this one would too.
Not to mention that I can think of at least 3 different cases that will all have
slightly different behavior that is inexplicable to users at best and
infuriating
at worst.

\[ a

b \]

\[
a
b
\]

a \[ b

c \] d

etc. There are plenty more variants that would all be subtly different depending
on the exact way such a thing were implemented.

In short. Just not worth it.


  reply	other threads:[~2021-10-04  5:58 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-30 17:20 [PATCH] Don't fill displayed equations Timothy
2021-09-30 17:44 ` Timothy
2021-09-30 18:51 ` Nicolas Goaziou
2021-09-30 18:54   ` Timothy
2021-09-30 19:02     ` Nicolas Goaziou
2021-09-30 19:17       ` Colin Baxter
2021-09-30 22:11         ` Nicolas Goaziou
2021-09-30 22:26           ` Tim Cross
2021-09-30 19:28       ` Timothy
2021-09-30 20:45       ` Timothy
2021-09-30 22:55         ` Nicolas Goaziou
2021-10-01  7:38           ` Stefan Nobis
2021-10-01 20:41             ` Nicolas Goaziou
2021-10-02  8:17               ` Org syntax: \[ \] as block element instead of inline object Max Nikulin
2021-10-02 10:47                 ` Stefan Nobis
2021-10-02  9:57               ` [PATCH] Don't fill displayed equations Stefan Nobis
2021-10-02 10:04               ` Eric S Fraga
2021-10-02 10:18                 ` Timothy
2021-10-02 11:24                   ` Eric S Fraga
2021-10-02 14:21                     ` Max Nikulin
2021-10-02 17:51                       ` Tom Gillespie
2021-10-02 18:28                         ` Timothy
2021-10-02 18:57                           ` Tom Gillespie
2021-10-02 20:25                             ` org-latex-preview and latex export blocks Timothy
2021-10-03  8:50                         ` [PATCH] Don't fill displayed equations Max Nikulin
2021-10-03 10:56                           ` Stefan Nobis
2021-10-03 12:04                             ` Max Nikulin
2021-10-04  5:57                               ` Tom Gillespie [this message]
2021-10-04 17:11                                 ` Max Nikulin
2021-10-03 12:35                           ` Ihor Radchenko
2021-10-01  7:43           ` Timothy
2021-10-02 11:06             ` Nicolas Goaziou
2021-10-02 11:24               ` Timothy
2021-10-03  8:49                 ` Ihor Radchenko
2021-10-03  8:50                   ` Timothy
2021-10-03  9:13                     ` Ihor Radchenko
2021-10-03  9:14                       ` Timothy
2021-10-03  9:41                         ` Ihor Radchenko
2021-10-03  9:42                           ` Timothy
2022-06-18  6:00                             ` Ihor Radchenko
2021-10-01 14:42         ` Greg Minshall
2021-10-04  6:05         ` Timothy
2021-10-04  7:11           ` Tom Gillespie
2021-10-04  7:15             ` Timothy
2021-10-04  8:11           ` Przemysław Pietrzak

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 \
    --in-reply-to='CA+G3_POJoVK0fWrMCHzLTNkogfwRHP47p=FWSt3i4edzyvgkRg@mail.gmail.com' \
    --to=tgbugs@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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
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

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