Hello,
Aaron Ecay <aarone...@gmail.com> 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
`org-use-sub-superscripts'.
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).
Regards,
--
Nicolas Goaziou
