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
