[Top][All Lists]

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

Re: [O] [parser] subscripts and underlines interacting badly

From: Nicolas Goaziou
Subject: Re: [O] [parser] subscripts and underlines interacting badly
Date: Wed, 11 Dec 2013 09:22:04 +0100


Aaron Ecay <address@hidden> writes:

> I have encountered two related misbehaviors in the parser/exporter.
> The first manifests if you type the following line into an org-mode
> buffer and execute M-: (org-element-context) with point on the ‘f’; the
> result is a subscript object, whereas I would have expected an
> underline:
> '_foo_
> I think both possibilities are returned by
> org-element--get-next-object-candidates, and subscript “wins” because it
> precedes the other in the list.  I’m not sure how this should be
> addressed, but maybe Nicolas knows.

Actually, this is not really a parser problem but a syntax one.
underline and subscript are ambiguous, and therefore ill-defined,
because, in some situations, both can match at the same location.

This is usually not noticeable because, I think, most uses of underline
begin with a space (e.g. some _word_) whereas subscript cannot. This is
not true in your example.

This has been discussed some months ago, but, AFAIR, no answer was
found. Note that I suggested a change to superscript/supscript a couple
of weeks ago, but it won't solve the problem at hand. Perhaps it could
be extended to remove ambiguity for subscript.

> I encountered the second issue when trying to hack around the first by
> setting org-use-sub-superscripts to '{}.  It seems this variable is not
> considered by the parser.  I think the attached patch fixes this
> issue.

Thanks for the patch.

Though, the parser ignores `org-use-sub-superscripts' on purpose. At the
moment `org-use-sub-superscripts' is a display variable only.

This change happened in 8.0. This also explains why
`org-export-with-sub-superscripts' is now a separate value from

The main reason for this change is that I think that customizable
syntax, unlike to customizable behaviour, is not a good idea for Org
(e.g. portability and simplicity issues).


Nicolas Goaziou

reply via email to

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