emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: heroxbd@gentoo.org
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] curly nested latex fragments
Date: Mon, 30 Jun 2014 14:31:28 +0200	[thread overview]
Message-ID: <87pphqmvdr.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <86k37zi63g.fsf@moguhome00.in.awa.tohoku.ac.jp> (heroxbd@gentoo.org's message of "Mon, 30 Jun 2014 09:38:59 +0900")


heroxbd@gentoo.org writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> I do not mind extending syntax for LaTeX macros a bit if it helps users,
>> but first, I would like a clear definition of what subset of macros
>> should be supported in Org.
>> See, for example,
>>   http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments
> \ce{^{238}U} falls into \NAME POST, doesn't it?

Sorry I wasn't clear. I suggested to not use a regexp to describe the
syntax, as regular expressions may not be sufficient to describe the
object. Try to use something like the link above.

Also, bear in mind that a complicated regexp slows down parsing.

> Ha, I don't even aware of <...> syntex as a part of the LaTeX macro; I
> just copied the regex from org-latex.el.  So let's strip it out, and
> advise the users to use explicit LaTeX block for <...> constructs.
> + (looking-at (concat
> +              "\\\\\\([a-zA-Z]+\\*?\\)"
> +              "\\(?:\\[[^][\n]*?\\]\\)*"
> +              "\\(" (org-create-multibrace-regexp "{" "}" 3) "\\)\\{1,3\\}"))

Unfortunately, this is ambiguous with Org macro syntax.  For example, it
would match:


which is an entity followed by a macro.

> Do you mean this[2] and this[3] threads?  I've read them through, and
> remotely understood the difficulty coming from the ambiguity of the
> syntax.  And as discussed above, the difficulty manifests in the
> definition of LaTeX fragments, too.

There is no ambiguity in LaTeX fragments, as Org is not required to
support full raw LaTeX syntax (and never did anyway), as long as we
provide markup to insert LaTeX in the buffer anyway.

If we can support a bit more without introducing corner cases, that's
fine. But, as you say, that's just syntactic sugar, so pure Org syntax
goes first.

> At the same time, these syntax sugar is great.  And that's the reason
> why we prefer org-mode in composing LaTeX to pristine LaTeX.  There is a
> sincere need to compromise the cleanness of the implementation for the
> sake of an ambiguous-but-human-intuitive syntax.

@@l:\ce{^{238}U}@@ is not so bad, nor is {{{ce(^{238)U)}}} with
a properly defined macro template.

Anyway, let me stress it again: a change to macro syntax is fine if it
introduces no ambiguity. Obviously, the same holds for sub/superscript.

> To resolve this dilemma, we need a formal (mathematically rigorous) org
> syntex specification, like the rules drafted in
>   http://orgmode.org/worg/dev/org-syntax.html#Entities_and_LaTeX_Fragments
> together with a set of test suites to demonstrate the spec.  There would
> be a lot of work, but we could start from embedded LaTeX fragments and
> super(sub)scripts/underline.
> It might be mentally overwhelming for one single guy to do the spec and
> the implementation at the same time, because they require different
> mindsets.  The spec is long term and should be stable while the
> implementation is always being optimized.  After all, it is considered
> good practice to make the two processes independent to each other.

I'm not sure what do you mean. "org-syntax.html" describes, well, the
syntax (although it could be better, with, e.g., EBNF, help is welcome),
"org-element.el" implements it, with optimizations, and
"test-org-element.el" tests the implementation.

Anyway, let's concentrate on LaTeX macros.


Nicolas Goaziou

  reply	other threads:[~2014-06-30 12:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 10:42 Bug: [regression] superscript not available after non-alphanumeric [8.2.7b (8.2.7b-dist @ /home/benda/gnto/usr/share/emacs/site-lisp/org-mode/)] heroxbd
2014-06-27 11:55 ` Nicolas Goaziou
2014-06-28  1:39   ` syntax specification (was Re: Bug: [regression] superscript not available after non-alphanumeric) heroxbd
2014-06-29 11:47   ` [PATCH] curly nested latex fragments (was: " heroxbd
2014-06-29 13:53     ` [PATCH] curly nested latex fragments Nicolas Goaziou
2014-06-30  0:38       ` heroxbd
2014-06-30 12:31         ` Nicolas Goaziou [this message]
2014-06-30 21:50           ` heroxbd
2014-07-06 20:11             ` Nicolas Goaziou

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=87pphqmvdr.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=heroxbd@gentoo.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).