From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] [PATCH] [babel] read description lists as lists of lists Date: Fri, 26 Sep 2014 11:03:50 +0200 Message-ID: <877g0qeosp.fsf@nicolasgoaziou.fr> References: <87ha03qv19.fsf@gmail.com> <87ha02a4qg.fsf@nicolasgoaziou.fr> <87d2anougv.fsf@gmail.com> <87tx3weqrv.fsf@nicolasgoaziou.fr> <87oau4my5o.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]:50845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXRQw-0008Qb-Lb for emacs-orgmode@gnu.org; Fri, 26 Sep 2014 05:03:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXRQo-0001BJ-0T for emacs-orgmode@gnu.org; Fri, 26 Sep 2014 05:03:22 -0400 Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]:58681) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXRQn-00019A-Nm for emacs-orgmode@gnu.org; Fri, 26 Sep 2014 05:03:13 -0400 Received: from mfilter40-d.gandi.net (mfilter40-d.gandi.net [217.70.178.171]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id A9F2B41C093 for ; Fri, 26 Sep 2014 11:03:07 +0200 (CEST) Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter40-d.gandi.net (mfilter40-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eX3A--5-XncL for ; Fri, 26 Sep 2014 11:03:06 +0200 (CEST) Received: from selenimh (unknown [91.224.148.150]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 1D58041C096 for ; Fri, 26 Sep 2014 11:03:04 +0200 (CEST) In-Reply-To: <87oau4my5o.fsf@gmail.com> (Aaron Ecay's message of "Wed, 24 Sep 2014 18:49:55 -0400") 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: Org-mode Hello, Aaron Ecay writes: > Isn=E2=80=99t the org-element format also easy to work on? It requires a= bit > more than just car and cdr, but it=E2=80=99s well documented and used in = many > places across the code base (=3D cognitive burden to use is lower). It= =E2=80=99s > also easy to produce in the sense that org-element.el already exists for > independent reasons; we just have to use it. It is not as easy to produce ex nihilo, i.e., without any Org syntax under point. But, really, I do not mind if both radio lists and Babel move to this internal syntax. It will require much more work, though. Also, it doesn't mean we can remove or replace `org-list-parse-list' and `org-list-to-generic'. > Radio lists is a feature, org-list-to-generic is an implementation. We > can change the implementation without changing the user-visible aspects > of the feature. IOW, nothing about the user-facing functionality of > org-list-to-generic requires it to accept a particular type of argument > (as long as that arg is some representation or other of a list). I agree. > One approach would be to detect when it=E2=80=99s called from a non-org-m= ode > buffer, and copy the text into a temporary org-mode buffer for parsing. > Then org-element would be available. Of course, if the internal representation is changed to Elements', that is probably the way to go. > IDK. You=E2=80=99re probably in a better position to know that than I am= . There=E2=80=99s > only one message even mentioning them (very tangentially) in my 2-ish yea= rs > of messages from the list: . > I=E2=80=99m not advocating their removal or deprecation, but they certain= ly seem > like the tail and not the dog when considering what parts of org ought to > wag what others. I think you are missing my point. Again, I'm fine with any improvement needed for Babel, but other, even remotely, related parts should be moved along. This is about consistency. I certainly don't want to see various parts of Org drift away. Or, to put it differently: mind the tail, do not act as if the dog had none. > Why? Babel=E2=80=99s representation is for babel. Which I strongly frown upon. > org-list-parse-list/-to-generic=E2=80=99s is for radio lists (although as= I=E2=80=99ve > said this connection seems accidental rather than essential). Babel > calls org-list-parse-list, but I don=E2=80=99t see why it should be forbi= dden > from doing more processing on the result before passing it along > (indeed, it already does some processing to remove the list type > indicators, remove nested structure, etc.). It is best to use as much common ground as possible. We should strive to decrease need for such processing, not the other way. As I already stated in my first answer, in the long run, it is the only sane way to proceed. I agree it is less work to simply tweak Babel right now and ignore the whole Org ecosystem, but it does no good to Org as a whole. > I dunno if I=E2=80=99d call my proposal an =E2=80=9Cinternal plain list r= epresentation,=E2=80=9D > but rather =E2=80=9Cbabel=E2=80=99s interpretation of plain lists.=E2=80= =9D See above. > Ordered and unordered lists are lists of strings (exactly as now). > Description lists are lists of 2-element lists, each of the form > (=E2=80=9CTERM=E2=80=9D =E2=80=9CDESCRIPTION=E2=80=9D) (unlike now, when = they are lists of strings of > the form =E2=80=9CTERM :: DESCRIPTION=E2=80=9D). > > It might be nice to handle nested lists somehow, if a sensible design > can be created, but it looks like babel just discards them currently. > So I propose to leave this unchanged, for the present at least: `org-list-parse-list' handles nested lists just fine. Another advantage of not re-inventing the wheel in every part of Org. Regards, --=20 Nicolas Goaziou 0x80A93738