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.
Okay.
Cheers,
Benda
next prev parent 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:
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=86r426gj8k.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).