From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [parser] subscripts and underlines interacting badly Date: Thu, 12 Dec 2013 21:47:32 +0100 Message-ID: <87lhzpx0d7.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> 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]:60003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrDAL-0007Q3-CQ for emacs-orgmode@gnu.org; Thu, 12 Dec 2013 15:47:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VrDA9-0004ja-Sn for emacs-orgmode@gnu.org; Thu, 12 Dec 2013 15:47:25 -0500 Received: from mail-ee0-x234.google.com ([2a00:1450:4013:c00::234]:39406) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VrDA9-0004hk-I2 for emacs-orgmode@gnu.org; Thu, 12 Dec 2013 15:47:13 -0500 Received: by mail-ee0-f52.google.com with SMTP id d17so491069eek.39 for ; Thu, 12 Dec 2013 12:47:12 -0800 (PST) Received: from selenimh ([91.224.148.150]) by mx.google.com with ESMTPSA id g7sm70102668eet.12.2013.12.12.12.47.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Dec 2013 12:47:11 -0800 (PST) In-Reply-To: <87ob4lkhmo.fsf@gmail.com> (Aaron Ecay's message of "Thu, 12 Dec 2013 14:42:28 -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: > 2013ko abenudak 12an, Nicolas Goaziou-ek idatzi zuen: >> >> We could give priority to underline when there are no curly brackets, >> priority to subscript otherwise. It sounds overly complicated though. > > Your last sentence sounds very close to "don=E2=80=99t do it; I won=E2=80= =99t accept > such a patch." Is that so? No, it just means that I didn't put much thought into it. It also means that I would prefer something more natural (and simpler) than such an ad-hoc rule. If you work on it and really think it is an improvement over existing situation, then I don't see why I wouldn't accept it. But I'd rather not consider it as a definitive answer to the problem (and include it as a part of a standard Org syntax implementation). > 1. You have a plan to get rid of org-use-sub-superscripts. You might also > want to get rid of `org-export-with-sub-superscripts' (depending on how > one interprets your remark that the variable "do[es]n't make much sense > anyway"). Also, other parts of org (e.g. the parser) cannot change to > harmonize with these variables. This means that these variables are de > facto deprecated, and org is headed to a future where sub/superscripts > are non-optional and non-configurable. and non-intrusive, too, which isn't the case at the moment. You cannot get rid of subscript in LaTeX (well, you probably can, but I guess most users don't). Why could you in Org? > 2. The current (non-optional, non-configurable) implementation of > X-scripts by the parser has specifically identifiable defects, > such as the one I mentioned whereby '_foo_, perhaps naturally > interpreted as underlining (among other reasons because of how it > is highlighted by org) is "really" a subscript. The current implementation, with its defects, is still configurable. `org-export-with-sub-superscripts' works as advertised, AFAIK. > 3. These inconsistencies cannot (or ought not) be addressed except by > some notional change to org syntax, which only you can (ought) make, > and which you=E2=80=99re not willing to discuss except in negative ter= ms > ("don=E2=80=99t do it that way"). I'm not really able to change Org syntax without Carsten's consent. Anyway, I'd like any syntax change to be really discussed. Org has a long history of great ideas implemented without any consistent syntax in mind. Examples include @, Babel's #+header line with ":prop value" (even though every other part of Org used "key=3Dvalue"), configurable emphasis markers and list item bullets, "comment" and "quote" keywords (even though Archive is a tag)... Also, changing Org syntax isn't limited to a mere patch over org-element.el. Remember that most of Org doesn't use this library (hint). Back to the topic. As you know, I'm not really open to per-user Org syntax. But I will consider any syntactical change that would solve the problem at hand. > I hope you realize why this situation might be frustrating to a user and > attempted contributor. I don't want to be frustrating. I try to make as clear as possible what I see as important and where I would like to head to. I even suggested topics to work on (e.g. escaped characters). There's also optimization to do on cache, if you're motivated. > PS I guess you might be frustrated too. You mentioned your previous > proposal about changing the regex which recognized X-scripts. I read > the thread at the time, and didn=E2=80=99t say anything because I didn=E2= =80=99t have a > strong opinion one way or the other; it simply looked like a reasonable, > incremental change and you were getting positive feedback. I=E2=80=99ve = re-read > the thread, and FWIW I think you should install the change, if you have > not done so. I again don=E2=80=99t have an opinion on the question about > grouping with parentheses which was left hanging at the end of the > thread. Coming from a latex background, it would never occur to me to > use parentheses to bracket an X-script. So it would not bother me if > you removed parenthesis-grouping as it seems you want to do. It is not applied. I am waiting for Carsten's green light about parenthesis-grouping removal. > PPS Also FWIW and again coming from a latex background, I think that > "bare" X-scripts such as a_b are always somewhat suspect. I would be > happy if org required brackets for X-scripts, always. I think this > would simplify the parsing problem a lot. But I don=E2=80=99t know if th= is > could have support enough to be implemented. You are right, it would simplify parsing. But it is very handy for note taking. I wouldn't suggest to remove it. Regards, --=20 Nicolas Goaziou