Re: LaTeX-export: letters after $..$ turn off math-mode

[Nicolas Goaziou <n.goaziou@gmail.com>]

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