Problem with org-entities-user

Problem with org-entities-user

[Thomas S. Dye]

Aloha all,

I'm probably doing something silly here, but can't figure it out.  Using
the new LaTeX exporter, and with org-entities-user defined as below,
this:

\C14 \frac12 \Omacron

exports as:

\C14 \textonehalf{} \={O}

Why isn't my C14 entity being exported correctly?

All the best,
Tom

Value: (("U234" "\\textsuperscript{234}U" nil "<sup>234</sup>U" "234U" "234U" "234U")
 ("Th230" "\\textsuperscript{230}Th" nil "<sup>230</sup>Th" "230Th" "230Th" "230Th")
 ("C14" "\\textsuperscript{14}C" nil "" "14C" "14C" "14C")
 ("Umacron" "\\={U}" nil "&#0362" "U" "U" "Ū")
 ("Omacron" "\\={O}" nil "&#0332" "O" "O" "Ō")
 ("Imacron" "\\={I}" nil "&#0298" "I" "I" "Ī")
 ("Emacron" "\\={E}" nil "&#0274" "E" "E" "Ē")
 ("Amacron" "\\={A}" nil "&#0256" "A" "A" "Ā")
 ("umacron" "\\={u}" nil "&#0363" "u" "u" "ū")
 ("omacron" "\\={o}" nil "&#0333" "o" "o" "ō")
 ("imacron" "\\={i}" nil "&#0299" "i" "i" "ī")
 ("emacron" "\\={e}" nil "&#0275" "e" "e" "ē")
 ("amacron" "\\={a}" nil "&#0257" "a" "a" "ā")
 ("space" "\\ " nil " " " " " " " "))

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: Problem with org-entities-user

[Nicolas Goaziou]

Hello,

tsd@tsdye.com (Thomas S. Dye) writes:

> I'm probably doing something silly here, but can't figure it out.  Using
> the new LaTeX exporter, and with org-entities-user defined as below,
> this:
>
> \C14 \frac12 \Omacron
>
> exports as:
>
> \C14 \textonehalf{} \={O}
>
> Why isn't my C14 entity being exported correctly?
>
> All the best,
> Tom
>
> Value: (("U234" "\\textsuperscript{234}U" nil "<sup>234</sup>U" "234U" "234U" "234U")
>  ("Th230" "\\textsuperscript{230}Th" nil "<sup>230</sup>Th" "230Th" "230Th" "230Th")
>  ("C14" "\\textsuperscript{14}C" nil "" "14C" "14C" "14C")
>  ("Umacron" "\\={U}" nil "&#0362" "U" "U" "Ū")
>  ("Omacron" "\\={O}" nil "&#0332" "O" "O" "Ō")
>  ("Imacron" "\\={I}" nil "&#0298" "I" "I" "Ī")
>  ("Emacron" "\\={E}" nil "&#0274" "E" "E" "Ē")
>  ("Amacron" "\\={A}" nil "&#0256" "A" "A" "Ā")
>  ("umacron" "\\={u}" nil "&#0363" "u" "u" "ū")
>  ("omacron" "\\={o}" nil "&#0333" "o" "o" "ō")
>  ("imacron" "\\={i}" nil "&#0299" "i" "i" "ī")
>  ("emacron" "\\={e}" nil "&#0275" "e" "e" "ē")
>  ("amacron" "\\={a}" nil "&#0257" "a" "a" "ā")
>  ("space" "\\ " nil " " " " " " " "))

That's because numbers are not allowed in entities, except for a few
exceptions:

  "\\\\\\(there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\($\\|{}\\|[^[:alpha:]]\\)"

Note that this regexp also matches LaTeX commands.

One seducing idea would be to drop support for such commands (I'm _not_
talking about math environments and snippets, but about commands like
\hfill{} or \bigskip{}). After all, if you want to write raw LaTeX in an
Org buffer, you can always use #+LATEX: or @@latex:...@@ like with any
other back-end. I see no compelling reason to keep this convenience if
it gets in the way.

It would speed-up a bit entities matching, and would allow for a relaxed
regexp (i.e. a regexp built upon already defined entities).


Regards,

-- 
Nicolas Goaziou

Re: Problem with org-entities-user

[Thomas S. Dye]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> I'm probably doing something silly here, but can't figure it out.  Using
>> the new LaTeX exporter, and with org-entities-user defined as below,
>> this:
>>
>> \C14 \frac12 \Omacron
>>
>> exports as:
>>
>> \C14 \textonehalf{} \={O}
>>
>> Why isn't my C14 entity being exported correctly?
>>
>> All the best,
>> Tom
>>
>> Value: (("U234" "\\textsuperscript{234}U" nil "<sup>234</sup>U"
>> "234U" "234U" "234U")
>>  ("Th230" "\\textsuperscript{230}Th" nil "<sup>230</sup>Th" "230Th"
>> "230Th" "230Th")
>>  ("C14" "\\textsuperscript{14}C" nil "" "14C" "14C" "14C")
>>  ("Umacron" "\\={U}" nil "&#0362" "U" "U" "Ū")
>>  ("Omacron" "\\={O}" nil "&#0332" "O" "O" "Ō")
>>  ("Imacron" "\\={I}" nil "&#0298" "I" "I" "Ī")
>>  ("Emacron" "\\={E}" nil "&#0274" "E" "E" "Ē")
>>  ("Amacron" "\\={A}" nil "&#0256" "A" "A" "Ā")
>>  ("umacron" "\\={u}" nil "&#0363" "u" "u" "ū")
>>  ("omacron" "\\={o}" nil "&#0333" "o" "o" "ō")
>>  ("imacron" "\\={i}" nil "&#0299" "i" "i" "ī")
>>  ("emacron" "\\={e}" nil "&#0275" "e" "e" "ē")
>>  ("amacron" "\\={a}" nil "&#0257" "a" "a" "ā")
>>  ("space" "\\ " nil " " " " " " " "))
>
> That's because numbers are not allowed in entities, except for a few
> exceptions:
>
>   "\\\\\\(there4\\|sup[123]\\|frac[13][24]\\|[a-zA-Z]+\\)\\($\\|{}\\|[^[:alpha:]]\\)"
>
> Note that this regexp also matches LaTeX commands.
>
> One seducing idea would be to drop support for such commands (I'm _not_
> talking about math environments and snippets, but about commands like
> \hfill{} or \bigskip{}). After all, if you want to write raw LaTeX in an
> Org buffer, you can always use #+LATEX: or @@latex:...@@ like with any
> other back-end. I see no compelling reason to keep this convenience if
> it gets in the way.
>
> It would speed-up a bit entities matching, and would allow for a relaxed
> regexp (i.e. a regexp built upon already defined entities).

Thanks Nicolas.  I was confused by the exceptional numbers into thinking
they were generally allowed.  

I'm not sure about support for \hfill{}, etc.  The new latex and html
exporters pass \hfill{} through unchanged, which might be what the latex
author wants, or what the html author writing about latex commands
wants. 

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Problem with org-entities-user

[Nicolas Goaziou]

Hello,

tsd@tsdye.com (Thomas S. Dye) writes:

> I'm not sure about support for \hfill{}, etc.  The new latex and html
> exporters pass \hfill{} through unchanged, which might be what the latex
> author wants, or what the html author writing about latex commands
> wants.

It would not change anything for the HTML author, since \hfill{} would
be exported as-is in any exporter. Though, it would be a less convenient
for the LaTeX author, who would have to type @@latex:\hfill{}@@.

On the other hand, I see at lest 3 reasons to remove support for such
constructs:

- consistency :: it's not possible to write raw HTML in an Org buffer,
                 nor raw Texinfo. LaTeX shouldn't be treated
                 differently.

- clarity :: Recently, an user expected the \cite{} command to work in
             a backend different from LaTeX.

- ecumenism :: Removing LaTeXisms will make Org documents easier to
               export to various back-ends.


Regards,

-- 
Nicolas Goaziou

Re: Problem with org-entities-user

[Carsten Dominik]

On 19 sep. 2012, at 15:15, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> tsd@tsdye.com (Thomas S. Dye) writes:
> 
>> I'm not sure about support for \hfill{}, etc.  The new latex and html
>> exporters pass \hfill{} through unchanged, which might be what the latex
>> author wants, or what the html author writing about latex commands
>> wants.
> 
> It would not change anything for the HTML author, since \hfill{} would
> be exported as-is in any exporter. Though, it would be a less convenient
> for the LaTeX author, who would have to type @@latex:\hfill{}@@.
> 
> On the other hand, I see at lest 3 reasons to remove support for such
> constructs:
> 
> - consistency :: it's not possible to write raw HTML in an Org buffer,
>                 nor raw Texinfo. LaTeX shouldn't be treated
>                 differently.
> 
> - clarity :: Recently, an user expected the \cite{} command to work in
>             a backend different from LaTeX.
> 
> - ecumenism :: Removing LaTeXisms will make Org documents easier to
>               export to various back-ends.

These are all valid arguments.  However, I did design
Org-mode to be LaTeX-near to make sure that it becomes
easy and fast to type as a notes environment.  In my mind, a user
expecting \cite{...} to work in other backends is not necessarily
a wrong expectation, and if we introduce a syntax for doing citations
in HTML, why not using the LaTeX syntax for it?

So actually, it seems I do not fully agree with your *consistency*
argument.  While you are right that it is the logical and clean thing
if you view Org as a markup language created for export, it is not
necessarily the right solution for a convenience point of view.

Just my 5c, of course...


- Carsten

Re: Problem with org-entities-user

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> These are all valid arguments.  However, I did design
> Org-mode to be LaTeX-near to make sure that it becomes
> easy and fast to type as a notes environment.  In my mind, a user
> expecting \cite{...} to work in other backends is not necessarily
> a wrong expectation, and if we introduce a syntax for doing citations
> in HTML, why not using the LaTeX syntax for it?
>
> So actually, it seems I do not fully agree with your *consistency*
> argument.  While you are right that it is the logical and clean thing
> if you view Org as a markup language created for export, it is not
> necessarily the right solution for a convenience point of view.

My point is not about removing anything related to LaTeX syntax. I'm
fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
long as it really is accepted by most major export back-ends.

But I think accepting raw commands like \vspace, \hfill and al. is not
necessary (as long as there's still a way to send them to the export
back-end). We shouldn't trick users into thinking these commands will be
obeyed in any situation.

Moreover, I don't think that they belong to an easy and fast to type
notes environment.


Regards,

-- 
Nicolas Goaziou

Re: Problem with org-entities-user

[Bastien]

Hi,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> My point is not about removing anything related to LaTeX syntax. I'm
> fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
> long as it really is accepted by most major export back-ends.
>
> But I think accepting raw commands like \vspace, \hfill and al. is not
> necessary (as long as there's still a way to send them to the export
> back-end). We shouldn't trick users into thinking these commands will be
> obeyed in any situation.

The contrast between \cite{...} and \hfill is interesting: the former
has an intuitive meaning in non-LaTeX backends too, so I agree
[[cite:...]] would be better here, but \hfill is a pure LaTeXism
(as are inline $...$ formulas for example.)

If we had a general syntax like [[cite:...]], then allowing the
\cite{...} latexism would be convenient but redundant, and we could
safely advise against using it.

But pure latexisms like \hfill have no intuitive equivalent in other
backends, and there is no ambiguity on what the user expects when he
uses this -- so accepting them is convenient.  Forcing #+LATEX: before
these constructs would slow down editing the buffer.

So here is the Occam's razor I suggest: let's generalize as much as
possible, and let's handle as much latexisms as possible.

-- 
 Bastien

Re: Problem with org-entities-user

[Thomas S. Dye]

Aloha all,

Bastien <bzg@altern.org> writes:

> Hi,
>
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> My point is not about removing anything related to LaTeX syntax. I'm
>> fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
>> long as it really is accepted by most major export back-ends.
>>
>> But I think accepting raw commands like \vspace, \hfill and al. is not
>> necessary (as long as there's still a way to send them to the export
>> back-end). We shouldn't trick users into thinking these commands will be
>> obeyed in any situation.
>
> The contrast between \cite{...} and \hfill is interesting: the former
> has an intuitive meaning in non-LaTeX backends too, so I agree
> [[cite:...]] would be better here, but \hfill is a pure LaTeXism
> (as are inline $...$ formulas for example.)
>
> If we had a general syntax like [[cite:...]], then allowing the
> \cite{...} latexism would be convenient but redundant, and we could
> safely advise against using it.
>
> But pure latexisms like \hfill have no intuitive equivalent in other
> backends, and there is no ambiguity on what the user expects when he
> uses this -- so accepting them is convenient.  Forcing #+LATEX: before
> these constructs would slow down editing the buffer.
>
> So here is the Occam's razor I suggest: let's generalize as much as
> possible, and let's handle as much latexisms as possible.

I wonder if the suggested razor is reasonable? Might it be better to
provide a mechanism for the user to generalize as much as possible and
have Org handle as many latexisms as needed to take fast notes?

I agree with Nicolas that having the regular expression recognize a
syntactically correct LaTeX command does not seem particularly useful if
Org isn't prepared to do the right thing in all cases. And, of course,
Org can't do the right thing in all cases because LaTeX isn't a fixed
target--there are new packages and commands introduced all the time.

Would the change to the regular expression that Nicolas proposes make it
possible to use org-entities-user more flexibly and practically as a way
to extend Org? I love the way org-entities takes care of all the export
backends *and* the display of the Org buffer. The examples that I used
to introduce this thread were unfortunately off the mark, and once I
stopped "thinking LaTeX" and started "thinking Org" I was able to
implement them perfectly with the existing Org facilities. Are there
examples of useful "entities" that would be made possible by Nicolas'
proposed change to the regular expression?

The other route I've found to extend Org (without messing the source
code) is links.  The approach I prefer parses the description (because
Org parses the path and I don't want to mess that up).  This works, but
it looks ugly in the Org buffer.  I'd love to be able to hook in a
function that told Org how to display my custom link :)

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: Problem with org-entities-user

[Carsten Dominik]

Hi Nicolas,

maybe first have to get clear what you mean by "not accepting raw commands".
Would that mean that if I write \vspace in the buffer, the LaTeX exporter
would then give me \textbackslash{}vspace, for example, because i thinks that
I want that text to appear in the output?

- Carsten

On 19 sep. 2012, at 17:55, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> These are all valid arguments.  However, I did design
>> Org-mode to be LaTeX-near to make sure that it becomes
>> easy and fast to type as a notes environment.  In my mind, a user
>> expecting \cite{...} to work in other backends is not necessarily
>> a wrong expectation, and if we introduce a syntax for doing citations
>> in HTML, why not using the LaTeX syntax for it?
>> 
>> So actually, it seems I do not fully agree with your *consistency*
>> argument.  While you are right that it is the logical and clean thing
>> if you view Org as a markup language created for export, it is not
>> necessarily the right solution for a convenience point of view.
> 
> My point is not about removing anything related to LaTeX syntax. I'm
> fine with a \cite{...} (although I think [[cite:...]] may be cleaner) as
> long as it really is accepted by most major export back-ends.
> 
> But I think accepting raw commands like \vspace, \hfill and al. is not
> necessary (as long as there's still a way to send them to the export
> back-end). We shouldn't trick users into thinking these commands will be
> obeyed in any situation.
> 
> Moreover, I don't think that they belong to an easy and fast to type
> notes environment.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

- Carsten

Re: Problem with org-entities-user

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> maybe first have to get clear what you mean by "not accepting raw commands".
> Would that mean that if I write \vspace in the buffer, the LaTeX exporter
> would then give me \textbackslash{}vspace, for example, because i thinks that
> I want that text to appear in the output?

Correct. This is the same when you type <p>something</p> in an Org
buffer and call the HTML back-end.


Regards,

-- 
Nicolas Goaziou

Re: Problem with org-entities-user

[Carsten Dominik]

On 20 sep. 2012, at 13:57, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> maybe first have to get clear what you mean by "not accepting raw commands".
>> Would that mean that if I write \vspace in the buffer, the LaTeX exporter
>> would then give me \textbackslash{}vspace, for example, because i thinks that
>> I want that text to appear in the output?
> 
> Correct. This is the same when you type <p>something</p> in an Org
> buffer and call the HTML back-end.


Yes, I see what you mean and it is indeed consistent.

The only thing is:  I do use Org to draft documents intended to
be later fine-tuned as LaTeX documents, while I don't usually
do this for other backends.  So the ability to put in naked
LaTeX formatting commands does have value and convenience for
me personally.

If the consent will be to remove this for cleanness and exporter
speed, maybe we could leave the code that does the protection
in an allow users to opt-in?

- Carsten

Re: Problem with org-entities-user

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> The only thing is:  I do use Org to draft documents intended to
> be later fine-tuned as LaTeX documents, while I don't usually
> do this for other backends.  So the ability to put in naked
> LaTeX formatting commands does have value and convenience for
> me personally.

If the LaTeX command doesn't require an argument, you can always add it
to `org-entities-user'. Otherwise, you may define a macro like the
following:

  #+MACRO: sc @@e-latex:\textsc{@@$1@@e-latex:}@@

I agree that's not as convenient to set up. But once it is done, it's as
easy to use as raw commands.

Anyway this is a minor point. I guess it will be swept under the rug of
historical reasons, after all.


Regards,

-- 
Nicolas Goaziou

Re: Problem with org-entities-user

[Carsten Dominik]

On 22.9.2012, at 10:52, Nicolas Goaziou wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> The only thing is:  I do use Org to draft documents intended to
>> be later fine-tuned as LaTeX documents, while I don't usually
>> do this for other backends.  So the ability to put in naked
>> LaTeX formatting commands does have value and convenience for
>> me personally.
> 
> If the LaTeX command doesn't require an argument, you can always add it
> to `org-entities-user'.

Yes, even though this is not very clean by itself.

> Otherwise, you may define a macro like the
> following:
> 
>  #+MACRO: sc @@e-latex:\textsc{@@$1@@e-latex:}@@
> 
> I agree that's not as convenient to set up. But once it is done, it's as
> easy to use as raw commands.

True.

> 
> Anyway this is a minor point. I guess it will be swept under the rug of
> historical reasons, after all.

Maybe not.  I can go along with your arguments for cleanness.  Would you object to keeping this feature in as an option, turned off be default, so that it is at least easy to keep lengthy files working?

The way I understand it, the new exporter will be default in 8.0, so this is the time to make some incompatible changes.  But if it is possible to support this as an option, I would like it.

Regards

- Carsten

Re: Problem with org-entities-user

[Thomas S. Dye]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 22.9.2012, at 10:52, Nicolas Goaziou wrote:
>
>> Hello,
>> 
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> 
>>> The only thing is:  I do use Org to draft documents intended to
>>> be later fine-tuned as LaTeX documents, while I don't usually
>>> do this for other backends.  So the ability to put in naked
>>> LaTeX formatting commands does have value and convenience for
>>> me personally.
>> 
>> If the LaTeX command doesn't require an argument, you can always add it
>> to `org-entities-user'.
>
> Yes, even though this is not very clean by itself.
>
>> Otherwise, you may define a macro like the
>> following:
>> 
>>  #+MACRO: sc @@e-latex:\textsc{@@$1@@e-latex:}@@
>> 
>> I agree that's not as convenient to set up. But once it is done, it's as
>> easy to use as raw commands.
>
> True.
>
>> 
>> Anyway this is a minor point. I guess it will be swept under the rug of
>> historical reasons, after all.
>
> Maybe not. I can go along with your arguments for cleanness. Would you
> object to keeping this feature in as an option, turned off be default,
> so that it is at least easy to keep lengthy files working?
>
> The way I understand it, the new exporter will be default in 8.0, so
> this is the time to make some incompatible changes. But if it is
> possible to support this as an option, I would like it.
>
> Regards
>
> - Carsten
>

I would like this, too. I think it would help me keep reproducible
research documents viable.

All the best,
Tom

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: Problem with org-entities-user

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 22.9.2012, at 10:52, Nicolas Goaziou wrote:
>> If the LaTeX command doesn't require an argument, you can always add it
>> to `org-entities-user'.
>
> Yes, even though this is not very clean by itself.

This is debatable. Entities are perfectly integrated into Org and are,
by essence, multiple-back-end friendly.

>> Anyway this is a minor point. I guess it will be swept under the rug of
>> historical reasons, after all.
>
> Maybe not. I can go along with your arguments for cleanness. Would you
> object to keeping this feature in as an option, turned off be default,
> so that it is at least easy to keep lengthy files working?

I'd rather leave it as it is, then. This option would require to
maintain two versions of the parser: one without LaTeX commands and
another one with them. That would defeat the whole point of removing
them.

> The way I understand it, the new exporter will be default in 8.0, so
> this is the time to make some incompatible changes.

Indeed. I will preserve my quota of backward-incompatible changes for
other things.


Regards,

-- 
Nicolas Goaziou

Re: Problem with org-entities-user

[Carsten Dominik]

On 23.9.2012, at 10:30, Nicolas Goaziou wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> On 22.9.2012, at 10:52, Nicolas Goaziou wrote:
>>> If the LaTeX command doesn't require an argument, you can always add it
>>> to `org-entities-user'.
>> 
>> Yes, even though this is not very clean by itself.
> 
> This is debatable. Entities are perfectly integrated into Org and are,
> by essence, multiple-back-end friendly.

I only mean in the sense that entities are made to insert symbols and characters, not to execute commands.  It certainly can be used to that, but this is not the intention of this mechanism.

> 
>>> Anyway this is a minor point. I guess it will be swept under the rug of
>>> historical reasons, after all.
>> 
>> Maybe not. I can go along with your arguments for cleanness. Would you
>> object to keeping this feature in as an option, turned off be default,
>> so that it is at least easy to keep lengthy files working?
> 
> I'd rather leave it as it is, then. This option would require to
> maintain two versions of the parser: one without LaTeX commands and
> another one with them. That would defeat the whole point of removing
> them.
> 
>> The way I understand it, the new exporter will be default in 8.0, so
>> this is the time to make some incompatible changes.
> 
> Indeed. I will preserve my quota of backward-incompatible changes for
> other things.


OK.

- Carsten

> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Re: Problem with org-entities-user

[Thomas S. Dye]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 23.9.2012, at 10:30, Nicolas Goaziou wrote:
>
>> Hello,
>> 
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> 
>>> On 22.9.2012, at 10:52, Nicolas Goaziou wrote:
>>>> If the LaTeX command doesn't require an argument, you can always add it
>>>> to `org-entities-user'.
>>> 
>>> Yes, even though this is not very clean by itself.
>> 
>> This is debatable. Entities are perfectly integrated into Org and are,
>> by essence, multiple-back-end friendly.
>
> I only mean in the sense that entities are made to insert symbols and
> characters, not to execute commands. It certainly can be used to that,
> but this is not the intention of this mechanism.
>

Yes, this is the essence of the mismatch.  The mechanism is designed to
work with entities, but the regular expression catches all LaTeX
commands, whose names don't distinguish entities from other constructs
AFAIK. 

>> 
>>>> Anyway this is a minor point. I guess it will be swept under the rug of
>>>> historical reasons, after all.
>>> 
>>> Maybe not. I can go along with your arguments for cleanness. Would you
>>> object to keeping this feature in as an option, turned off be default,
>>> so that it is at least easy to keep lengthy files working?
>> 
>> I'd rather leave it as it is, then. This option would require to
>> maintain two versions of the parser: one without LaTeX commands and
>> another one with them. That would defeat the whole point of removing
>> them.
>> 
>>> The way I understand it, the new exporter will be default in 8.0, so
>>> this is the time to make some incompatible changes.
>> 
>> Indeed. I will preserve my quota of backward-incompatible changes for
>> other things.
>
>
> OK.
>
Two versions of the parser!  Yikes, that doesn't sound good.

Links still provide a path to handle arbitrary LaTeX commands and have
them send sensible output to the different backends.  They don't look so
great in the Org buffer, but that is an aesthetic issue, not functional.

Thanks, Nicolas, for the new LaTeX exporter.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com