Superscripts and subscripts

Superscripts and subscripts

[Thomas S. Dye]

Aloha all,

With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
export. The space before the caret appears to be the problem.

All the best,
Tom

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

Re: Superscripts and subscripts

[Bastien]

Hi Thomas,

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

> With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
> correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
> export. The space before the caret appears to be the problem.

Confirmed -- this was reported already once.  I don't have a fix for
this at the moment, hopefully Nicolas can have a look sometime.

-- 
 Bastien

Re: Superscripts and subscripts

[Daniel Mahler]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

This works for me in org 7.9.2 and emacs 24.1.1, but chaining  as in
'x^{y}_{z}' will only fontify the ^{y} but not the _{z}, as I reported
earlier today, but 'x^{y} _{z}' will fontify both, just with an ugly gap in
the middle.

cheers
Daniel


On Tue, Apr 16, 2013 at 1:29 AM, Bastien <bzg@gnu.org> wrote:

> Hi Thomas,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
> > With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
> > correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
> > export. The space before the caret appears to be the problem.
>
> Confirmed -- this was reported already once.  I don't have a fix for
> this at the moment, hopefully Nicolas can have a look sometime.
>
> --
>  Bastien
>
>

[-- Attachment #2: Type: text/html, Size: 1320 bytes --]

Re: Superscripts and subscripts

[John Hendy]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Wed, Apr 17, 2013 at 9:57 PM, Daniel Mahler <dmahler@gmail.com> wrote:
> This works for me in org 7.9.2 and emacs 24.1.1, but chaining  as in
> 'x^{y}_{z}' will only fontify the ^{y} but not the _{z}, as I reported
> earlier today, but 'x^{y} _{z}' will fontify both, just with an ugly gap in
> the middle.

Ah. Googled around a bit. Are you sure you don't have something in
.emacs to set this? If not, perhaps the default settings just changed
since 7.9.2 and the current master branch, 8.0-pre. I found this upon
googling "fontify subscripts orgmode":
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00358.html

I added this to my buffer:

#+startup: entitiespretty

Now I get the attached. Indeed = ^{14}C= does not work for me, but
=x^{y}_{z}= does.


John



>
> cheers
> Daniel
>
>
> On Tue, Apr 16, 2013 at 1:29 AM, Bastien <bzg@gnu.org> wrote:
>>
>> Hi Thomas,
>>
>> tsd@tsdye.com (Thomas S. Dye) writes:
>>
>> > With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
>> > correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
>> > export. The space before the caret appears to be the problem.
>>
>> Confirmed -- this was reported already once.  I don't have a fix for
>> this at the moment, hopefully Nicolas can have a look sometime.
>>
>> --
>>  Bastien
>>
>

[-- Attachment #2: 2013-04-17_221801.png --]
[-- Type: image/png, Size: 13546 bytes --]

Re: Superscripts and subscripts

[Daniel Mahler]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

In my .emacs I have

(custom-set-variables
 ;;...
 '(org-pretty-entities t)
 '(org-use-sub-superscripts (quote {}))
;;...
)

but I get the opposite result ' ^{14}C' works , but 'x^{y}_{z}' does not,



On Wed, Apr 17, 2013 at 10:18 PM, John Hendy <jw.hendy@gmail.com> wrote:

> On Wed, Apr 17, 2013 at 9:57 PM, Daniel Mahler <dmahler@gmail.com> wrote:
> > This works for me in org 7.9.2 and emacs 24.1.1, but chaining  as in
> > 'x^{y}_{z}' will only fontify the ^{y} but not the _{z}, as I reported
> > earlier today, but 'x^{y} _{z}' will fontify both, just with an ugly gap
> in
> > the middle.
>
> Ah. Googled around a bit. Are you sure you don't have something in
> .emacs to set this? If not, perhaps the default settings just changed
> since 7.9.2 and the current master branch, 8.0-pre. I found this upon
> googling "fontify subscripts orgmode":
> - http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00358.html
>
> I added this to my buffer:
>
> #+startup: entitiespretty
>
> Now I get the attached. Indeed = ^{14}C= does not work for me, but
> =x^{y}_{z}= does.
>
>
> John
>
>
>
> >
> > cheers
> > Daniel
> >
> >
> > On Tue, Apr 16, 2013 at 1:29 AM, Bastien <bzg@gnu.org> wrote:
> >>
> >> Hi Thomas,
> >>
> >> tsd@tsdye.com (Thomas S. Dye) writes:
> >>
> >> > With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
> >> > correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
> >> > export. The space before the caret appears to be the problem.
> >>
> >> Confirmed -- this was reported already once.  I don't have a fix for
> >> this at the moment, hopefully Nicolas can have a look sometime.
> >>
> >> --
> >>  Bastien
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 2804 bytes --]

Re: Superscripts and subscripts

[Daniel Mahler]

[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]

upgrading to trunk gives me the same behaviour as John reported,
which, while not perfect, is better for tensors.


On Wed, Apr 17, 2013 at 10:54 PM, Daniel Mahler <dmahler@gmail.com> wrote:

> In my .emacs I have
>
> (custom-set-variables
>  ;;...
>  '(org-pretty-entities t)
>  '(org-use-sub-superscripts (quote {}))
> ;;...
> )
>
> but I get the opposite result ' ^{14}C' works , but 'x^{y}_{z}' does not,
>
>
>
> On Wed, Apr 17, 2013 at 10:18 PM, John Hendy <jw.hendy@gmail.com> wrote:
>
>> On Wed, Apr 17, 2013 at 9:57 PM, Daniel Mahler <dmahler@gmail.com> wrote:
>> > This works for me in org 7.9.2 and emacs 24.1.1, but chaining  as in
>> > 'x^{y}_{z}' will only fontify the ^{y} but not the _{z}, as I reported
>> > earlier today, but 'x^{y} _{z}' will fontify both, just with an ugly
>> gap in
>> > the middle.
>>
>> Ah. Googled around a bit. Are you sure you don't have something in
>> .emacs to set this? If not, perhaps the default settings just changed
>> since 7.9.2 and the current master branch, 8.0-pre. I found this upon
>> googling "fontify subscripts orgmode":
>> - http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00358.html
>>
>> I added this to my buffer:
>>
>> #+startup: entitiespretty
>>
>> Now I get the attached. Indeed = ^{14}C= does not work for me, but
>> =x^{y}_{z}= does.
>>
>>
>> John
>>
>>
>>
>> >
>> > cheers
>> > Daniel
>> >
>> >
>> > On Tue, Apr 16, 2013 at 1:29 AM, Bastien <bzg@gnu.org> wrote:
>> >>
>> >> Hi Thomas,
>> >>
>> >> tsd@tsdye.com (Thomas S. Dye) writes:
>> >>
>> >> > With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
>> >> > correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
>> >> > export. The space before the caret appears to be the problem.
>> >>
>> >> Confirmed -- this was reported already once.  I don't have a fix for
>> >> this at the moment, hopefully Nicolas can have a look sometime.
>> >>
>> >> --
>> >>  Bastien
>> >>
>> >
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3355 bytes --]

Re: Superscripts and subscripts

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
>> correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
>> export. The space before the caret appears to be the problem.
>
> Confirmed -- this was reported already once.  I don't have a fix for
> this at the moment, hopefully Nicolas can have a look sometime.

I made a non-whitespace character compulsory before the sub/superscript
marker a while ago, in order to circumvent a parsing problem.

Indeed, there is a parsing ambiguity between subscript and underline.
Consider the following example:

  _example_

According to the syntax it can be either an underlined "example" string
or a subscript "example" string followed by an underscore string. Both
are valid interpretations.

Of course, we could work around this with a new rule saying "the longest
match wins", which, in this case, is the underline. But it would be
better to find a more elegant solution, one which would remove the sole
ambiguity, AFAICT, in Org syntax.

Suggestions welcome.


Regards,

-- 
Nicolas Goaziou

Re: Superscripts and subscripts

[Achim Gratz]

Nicolas Goaziou writes:
> Of course, we could work around this with a new rule saying "the longest
> match wins", which, in this case, is the underline. But it would be
> better to find a more elegant solution, one which would remove the sole
> ambiguity, AFAICT, in Org syntax.
>
> Suggestions welcome.

How about {}^{14}C or {^{14}}C?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Superscripts and subscripts

[Thomas S. Dye]

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> Of course, we could work around this with a new rule saying "the longest
>> match wins", which, in this case, is the underline. But it would be
>> better to find a more elegant solution, one which would remove the sole
>> ambiguity, AFAICT, in Org syntax.
>>
>> Suggestions welcome.
>
> How about {}^{14}C or {^{14}}C?

The LaTeX solution, which recognizes the superscript and subscript
symbols in math mode, would only require a change in the Org
documentation.  This works: \(^{14}\)C.

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: Superscripts and subscripts

[Christian Moe]

>> Nicolas Goaziou writes:
>>> Of course, we could work around this with a new rule saying "the longest
>>> match wins", which, in this case, is the underline. But it would be
>>> better to find a more elegant solution, one which would remove the sole
>>> ambiguity, AFAICT, in Org syntax.

How did this work before? I never tried subscript after whitespace. But
we had both superscript-after-whitespace and
underlining-with-underscores working at the same time, without the
ambiguity causing problems as far as I remember.

Indeed, it's very difficult to think of a case where wrapping something
in underscores should not mean underline because you'd want subscript or
superscript before and underscore after.

Though I'm sure there's an Org user out there with a use case. :)

> Achim Gratz <Stromeko@nexgo.de> writes:
>> How about {}^{14}C or {^{14}}C?

Works for me, I guess, if it has to be.

Thomas S. Dye writes:
> The LaTeX solution, which recognizes the superscript and subscript
> symbols in math mode, would only require a change in the Org
> documentation.  This works: \(^{14}\)C.

Yep, but in non-latex backends, a superscript that's native to the
backend would be a happier solution.

Yours,
Christian

Re: Superscripts and subscripts

[Nicolas Goaziou]

Hello,

Christian Moe <mail@christianmoe.com> writes:

>>> Nicolas Goaziou writes:
>>>> Of course, we could work around this with a new rule saying "the longest
>>>> match wins", which, in this case, is the underline. But it would be
>>>> better to find a more elegant solution, one which would remove the sole
>>>> ambiguity, AFAICT, in Org syntax.
>
> How did this work before? I never tried subscript after whitespace. But
> we had both superscript-after-whitespace and
> underlining-with-underscores working at the same time, without the
> ambiguity causing problems as far as I remember.

Simple: underline text was always handled (i.e. protected for further
transformation) before subscript.

But this doesn't remove the ambiguity. It just adds another parameter:
the parsing order.


Regards,

-- 
Nicolas Goaziou

Re: Superscripts and subscripts

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> Of course, we could work around this with a new rule saying "the longest
>> match wins", which, in this case, is the underline. But it would be
>> better to find a more elegant solution, one which would remove the sole
>> ambiguity, AFAICT, in Org syntax.
>>
>> Suggestions welcome.
>
> How about {}^{14}C or {^{14}}C?

It means that a white space before a sub/superscript marker is invalid.
In that case, we can also use "\nbsp" entity instead of {}. It's longer,
but more standard.

Another option would be to change syntax for underline, doubling the
underscore characters:

  __underline__

The other advantage is that it may be less ambiguous if we ever allow
text markup within words.


Regards,

-- 
Nicolas Goaziou