emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] plus in superscript.


From: Christian Moe
Subject: Re: [O] plus in superscript.
Date: Thu, 15 Sep 2011 09:43:57 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0

Hi,

$...$ may sometimes get confused with currency signs, variable names and whatnot.

Org-mode is sophisticated about it as long as you follow a few safeguards -- from the Info section 11.7.3:

     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.

But note that MathJax, the preferred backend for math in Org's HTML exports, does not support $...$ by default. To configure it, see:

http://www.mathjax.org/docs/1.1/tex.html#tex-and-latex-math-delimiters

Yours,

Christian

On 9/15/11 9:19 AM, Nick Dokos wrote:
suvayu ali<address@hidden>  wrote:

Hi Nick,

On Wed, Sep 14, 2011 at 6:55 PM, Nick Dokos<address@hidden>  wrote:
* This is a test: \(T^{+}\)

Apart from what Christian said, do you have any comments about $..$
and \(..\) ? I hear conflicting arguments about which is preferred
(e.g. $..$ is a TeX construct where as \(..\) is a LaTeX macro arguing
in favour of $..$). Specially an opinion in the context of org ->
latex export would be interesting to hear.


As far as LaTeX is concerned, I believe that $...$ and \(...\) are
entirely equivalent (but you have to use \[...\], and not $$...$$ for
displayed material). That's from reading Lamport's book: sec 3.3 and
Appendix E (the "Miscellaneous" section); I have not checked the code.

I prefer \(...\) and (iirc) sometimes that has worked when $...$ has
not, but I don't remember the context; afaik those (rare) situations
were deemed to be bugs in the exporter and have all been fixed.

Nick







reply via email to

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