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

[Nicolas Goaziou]

Aaron Ecay <address@hidden> writes:

> 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?

I don't know. Perhaps something as convoluted as:

  A'_{a_-1}

But that's not the real problem: whenever we change underline syntax
(e.g. if we implement escaped characters), we will start over again, as
more ambiguous cases might spawn.

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

As a short term solution, it can be implemented (it's probably just
a matter of reordering successors calls). But in the long run, we really
need to define properly both syntax.

> 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'm strongly against behavioral parts in Org syntax (even though the
ship probably has sailed long ago). Org mode is bound to Emacs, but Org
format should be platform independent.

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

Note that in my post, I said "at the moment". There are two variables
for historical reasons. AFAIC some `org-export-with-*' variables don't
make much sense anyway (`org-export-with-tables' comes to mind, but also
`org-export-with-sub-superscripts').

The real question is: why would we need to disable superscript/subscript
in an Org document? We probably need it because they can get in the way
sometimes. Then, we'd better provide tools to put them out of that way
instead of completely disabling them. Character escaping is one
solution.

Again, I strongly think we should focus on making Org syntax simpler
(and yet powerful) instead of piling up variables to change it on the
fly for occasional needs.


Regards,

-- 
Nicolas Goaziou