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

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

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

Wow that's exactly what I was wondering when reading
org-element--parse-{elements,objects}.  It is a tokenizer in lexical
analysis, for which great tools exist for decades.

>> 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:
>   \alpha{{{macro(arg)}}}
> which is an entity followed by a macro.

Err, insert a white space?

   \alpha {{{macro(arg)}}}

Or expand the macro before latex-or-entity matching.

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

I agree with you on this.

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

Hmmm, after reflection, my preference of \ce{^{238}U} comes from the
syntax of org-mode 7.9.

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

Sorry, it's my ignorance.  I didn't notice the tests/ dir.  So great
that the testing framework is already there.

> Anyway, let's concentrate on LaTeX macros.



  reply	other threads:[~2014-06-30 21:50 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
2014-06-30 21:50           ` heroxbd [this message]
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=86r426gj8k.fsf@moguhome00.in.awa.tohoku.ac.jp \
    --to=heroxbd@gentoo.org \
    --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).