From: heroxbd@gentoo.org
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] curly nested latex fragments
Date: Mon, 30 Jun 2014 09:38:59 +0900 [thread overview]
Message-ID: <86k37zi63g.fsf@moguhome00.in.awa.tohoku.ac.jp> (raw)
In-Reply-To: <87simng6tw.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Sun, 29 Jun 2014 15:53:47 +0200")
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Hello,
>
> heroxbd@gentoo.org 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".
I see, the regex used for latex protection (in org-latex.el) and
footnote guarding (org-footnotes.el org.el) are different.
>> 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
\ce{^{238}U} falls into \NAME POST, doesn't it?
> 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).
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\\}"))
> 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.
`org-inside-latex-macro-p' for example? Yeah, definitely.
>> 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.
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. It is frustrating to deal with
these corner cases, making a well-designed parser framework unnecessary
complex.
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.
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.
What do you think?
Yours,
Benda
1. http://orgmode.org/w/?p=org-mode.git;a=commit;h=88cf58802cc35dee2bc8ff8633b5c842fa7a23b3
2. http://thread.gmane.org/gmane.emacs.orgmode/79735
3. http://thread.gmane.org/gmane.emacs.orgmode/85902
next prev parent reply other threads:[~2014-06-30 0:39 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 [this message]
2014-06-30 12:31 ` Nicolas Goaziou
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:
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=86k37zi63g.fsf@moguhome00.in.awa.tohoku.ac.jp \
--to=heroxbd@gentoo.org \
--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).