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: heroxbd
Subject: Re: [O] [PATCH] curly nested latex fragments
Date: Tue, 01 Jul 2014 06:50:19 +0900
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi Nicolas,

Nicolas Goaziou <address@hidden> writes:

> address@hidden writes:
>
>> Nicolas Goaziou <address@hidden> 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



reply via email to

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