[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] LaTeX-export: letters after $..$ turn off math-mode
From: |
Nicolas Goaziou |
Subject: |
Re: [O] LaTeX-export: letters after $..$ turn off math-mode |
Date: |
Sat, 16 Feb 2013 12:48:16 +0100 |
Completing myself,
> IMO, I would call that an Org limitation. Org is not LaTeX, even if it
> provides many LaTeX facilities. Also, the OP's problem can be solved in
> many ways under Emacs. For example, I use "mt" (both "m" and "t" are on
> my home row) as a snippet to insert "\(\)" in an Org buffer and put
> point inside.
I would even go further. The following text has been in documentation
for years:
* Text within the usual LaTeX math delimiters. To avoid conflicts
with currency specifications, single `$' characters are only
recognized as math delimiters if the enclosed text contains at
most two line breaks, is directly attached to the `$' characters
with no whitespace in between, and if the closing `$' is followed
by whitespace, punctuation or a dash. For the other delimiters,
there is no such restriction, so when in doubt, use `\(...\)' as
inline math delimiters.
and so has been this excerpt from `org-inside-LaTeX-fragment-p'
docstring:
Even though the matchers for math are configurable, this function assumes
that \\begin, \\(, \\[, and $$ are always used. Only the single dollar
delimiters are skipped when they have been removed by customization.
This function does a reasonably good job, but can locally be fooled by
for example currency specifications. For example it will assume being in
inline math after \"$22.34\". The LaTeX fragment formatter will only format
fragments that are properly closed, but during editing, we have to live
with the uncertainty caused by missing closing delimiters.
We cannot afford two maintain two implementations, one of them being
frail, of the _same concept_. It's way better to focus on one of them,
and make sure it is solid. It also means a slightly lighter Org, and
less code to debug, which is always good.
Thus, I suggest to announce that $ (both $ and $$, even though $$ don't
have problems /per se/) symbols for should be avoided. Then, in a year
or so, we can remove them completely from code base.
Regards,
--
Nicolas Goaziou