emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] curly nested latex fragments


From: Nicolas Goaziou
Subject: Re: [O] [PATCH] curly nested latex fragments
Date: Sun, 29 Jun 2014 15:53:47 +0200

Hello,

address@hidden writes:

> Nesting braces is already implemented in the classic org-latex.el[1],
> and is forward ported into org-element.el.

Thanks for your patch.

I think you are misunderstanding something. I didn't port this
limitation in Org 8. AFAIK it has been there for a long time. See
`org-inside-latex-macro-p' for example.

The main problem with Org < 8 is that every exporter implemented its own
parser for the Org buffer. As you can see, "org-latex.el" was in
contradiction with "org.el".

> Would you like to take a look at the attached patch? Thanks.

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

Also, I do not want to add constructs like

  "\\(?:<[^<>\n]*>\\)*"

in this definition, as this isn't supported even in
`TeX-find-macro-end-helper' (from auctex), which I consider as
a reference for macro syntax (i.e. we shouldn't support more than what
is supports).

Eventually, please note that this imply to change not only
"org-element.el", but also "org.el" and possibly other parts where the
limitation is encoded. But first, we need to agree on what exactly
a valid a LaTeX macro is in Org.

> If \ce{^2H} works as above, it is not a problem for me.  Although make
> it configurable is more user-friendly; "^:{}" is already there afterall,
> adding another style feels natural.

It's not about adding another style. "^:{}" allows less (without
changing syntax, because the limitation is done at the export level),
you want to allow more, which implies to change syntax. I don't want the
latter to be configurable.

I explained in this thread why it wasn't possible, for the time being,
to allow a blank character before sub or superscript. This was discussed
on this ML, you may want to search archives.


Regards,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]