From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [parser] subscripts and underlines interacting badly Date: Wed, 11 Dec 2013 21:55:59 +0100 Message-ID: <8761qvxg2o.fsf@gmail.com> References: <87ppp415n4.fsf@gmail.com> <87bo0nu79v.fsf@gmail.com> <87haaf1bgi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqqow-0001ts-Cb for emacs-orgmode@gnu.org; Wed, 11 Dec 2013 15:55:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vqqon-0005EO-Vo for emacs-orgmode@gnu.org; Wed, 11 Dec 2013 15:55:50 -0500 Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]:53798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vqqon-0005EE-DJ for emacs-orgmode@gnu.org; Wed, 11 Dec 2013 15:55:41 -0500 Received: by mail-ee0-f42.google.com with SMTP id e53so3170295eek.1 for ; Wed, 11 Dec 2013 12:55:40 -0800 (PST) Received: from selenimh ([91.224.148.150]) by mx.google.com with ESMTPSA id b41sm57817416eef.16.2013.12.11.12.55.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Dec 2013 12:55:39 -0800 (PST) In-Reply-To: <87haaf1bgi.fsf@gmail.com> (Aaron Ecay's message of "Wed, 11 Dec 2013 13:36:45 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "emacs-orgmode@gnu.org" Aaron Ecay 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 =E2=80=9Cportability=E2=80=9D will wind up wagging the d= og 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=E2=80=99s output* from having to worry about the value of the vari= ables in > question. > > Finally, it would allow the re-unification of the export and display > flavors of the use-subscripts variable. It=E2=80=99s 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, --=20 Nicolas Goaziou