Re: [parser] subscripts and underlines interacting badly

[Aaron Ecay <aaronecay@gmail.com>]

Hi Nicolas,

Thanks for your comments.

2013ko abenudak 11an, Nicolas Goaziou-ek idatzi zuen:
> 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.

I have found one case where both match, but an underline is intended.
Are there any reverse cases, i.e. where both match but a subscript is
intended?  The closest I could come up with would be something like:

The quantities X_1 and X_2 are ....

But I think, at least with default values of
org-emphasis-regexp-components, this cannot be an underline.

So, if there are indeed no such cases, the fix is just to always choose
the underline, when both underline and subscript match at the same
position.

> 
> 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).

I understand your point.  But I think there is a danger in some cases
that the tail of “portability” will wind up wagging the dog of org-mode.
The syntax of org is an abstract mathematical object; the parser is just
one (currently the only, AFAIK) implementation of it.  So, if it proves
necessary, some behavioral aspects can be added to the parser, as long
as it is understood that they are behavioral and not driven by the
abstract syntax (we could add such a comment to my patch, for example).

I think it is advantageous to do so in this case.  In the example I
gave, two core parts of org (display and export) differ in their
interpretation of the same string.  Putting this behavior in the parser
will fix that.  It will also free future elisp code which consumes the
parser’s output* from having to worry about the value of the variables in
question.

Finally, it would allow the re-unification of the export and display
flavors of the use-subscripts variable.  It’s hard to think of a use
case that would want subscripts to be interpreted differently for
display and export.  (Although if someone has such a case, the
unification need not be undertaken: it is purely optional.)

Thanks again,

-- 
Aaron Ecay