From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [parser] subscripts and underlines interacting badly Date: Tue, 17 Dec 2013 17:57:45 +0100 Message-ID: <871u1b9zzq.fsf@gmail.com> References: <87ppp415n4.fsf@gmail.com> <87bo0nu79v.fsf@gmail.com> <87haaf1bgi.fsf@gmail.com> <8761qvxg2o.fsf@gmail.com> <87r49ik0qw.fsf@gmail.com> <87txeevus8.fsf@gmail.com> <87ob4lkhmo.fsf@gmail.com> <87lhzpx0d7.fsf@gmail.com> <87fvptfpuy.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]:57658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vsxxf-00060S-DM for emacs-orgmode@gnu.org; Tue, 17 Dec 2013 11:57:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VsxxX-000643-0G for emacs-orgmode@gnu.org; Tue, 17 Dec 2013 11:57:35 -0500 Received: from mail-ee0-x22b.google.com ([2a00:1450:4013:c00::22b]:39559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VsxxW-00063D-Q0 for emacs-orgmode@gnu.org; Tue, 17 Dec 2013 11:57:26 -0500 Received: by mail-ee0-f43.google.com with SMTP id c13so3014184eek.30 for ; Tue, 17 Dec 2013 08:57:25 -0800 (PST) Received: from selenimh ([91.224.148.150]) by mx.google.com with ESMTPSA id a51sm54628148eeh.8.2013.12.17.08.57.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2013 08:57:24 -0800 (PST) In-Reply-To: <87fvptfpuy.fsf@gmail.com> (Aaron Ecay's message of "Sun, 15 Dec 2013 22:15:33 -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" Hello, Aaron Ecay writes: > Since the present syntax is inadequate for representating these > sequences, the new syntax will have to break backwards compatibility > somehow in order to fix the problem. So there=E2=80=99s no long-term har= m in > having a short-term kludge that will eventually disappear. OK. Thanks for the patch. Though, I think you are patching the wrong location. Modifying `org-element--get-next-object-candidates' is expensive. It would be better to patch `org-element-sub/superscript-successor' and make it ignore underline matches with brackets followed by an underscore character and resume searching. > But eventually it will (assuming the cache implementation proves robust > enough), right? So, changes in org-element.el will eventually percolate > to the rest of org, whereas changes elsewhere will wither and dry up. But it will be a slow process, and, meanwhile both org-element and the rest of Org must be handled. > I don=E2=80=99t think escaped characters help with the problem that it is > presently impossible to represent the following (pseudo)-element > sequence in org syntax: [...] You are right, escaped characters cannot help us here. > Anyway, what do escaped characters do that entities cannot?=20=20 Not much. But they could be used in verbatim context. Also, they are somehow inconvenient to use, as you noticed. This can be troublesome in an environment also meant for note-taking. Regards, --=20 Nicolas Goaziou