Re: [parser] subscripts and underlines interacting badly

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

Hello,

Aaron Ecay <aaronecay@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