From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [RFC] [PATCH] [babel] read description lists as lists of lists Date: Wed, 24 Sep 2014 18:49:55 -0400 Message-ID: <87oau4my5o.fsf@gmail.com> References: <87ha03qv19.fsf@gmail.com> <87ha02a4qg.fsf@nicolasgoaziou.fr> <87d2anougv.fsf@gmail.com> <87tx3weqrv.fsf@nicolasgoaziou.fr> 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]:51197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWvNu-0005KU-69 for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 18:50:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWvNs-00059Y-Lz for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 18:50:06 -0400 Received: from mail-qg0-x229.google.com ([2607:f8b0:400d:c04::229]:48429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWvNs-00050f-GK for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 18:50:04 -0400 Received: by mail-qg0-f41.google.com with SMTP id j107so5669413qga.28 for ; Wed, 24 Sep 2014 15:49:59 -0700 (PDT) In-Reply-To: <87tx3weqrv.fsf@nicolasgoaziou.fr> 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: Nicolas Goaziou , Org-mode Hi Nicolas, Thanks for the discussion. 2014ko irailak 24an, Nicolas Goaziou-ek idatzi zuen: >=20 > You cannot do that. This is not about backwards compatibility. >=20 > `org-list-parse-list' generates an easy to produce and work on internal > representation for lists (similar to what `org-table-to-lisp' does for > tables).=20 Isn=E2=80=99t the org-element format also easy to work on? It requires a b= it more than just car and cdr, but it=E2=80=99s well documented and used in ma= ny 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. > `org-list-to-generic' is used for radio lists (similar to > `org-table-to-generic'): it is expected to consume a > `org-list-parse-list'-like return value. 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). >=20 > IOW both functions are important and are not meant to be replaced by > Elements (however, at some point `org-list-to-generic' should use > "ox.el", but that's for another day). ...doesn=E2=80=99t using ox.el entail using elements? >=20 > Note that since `org-list-parse-list' is meant for extraneous buffer, it > cannot rely on Elements. It shouldn't even use `org-list-struct' because > I plan to make this function use Elements, too. One approach would be to detect when it=E2=80=99s called from a non-org-mode buffer, and copy the text into a temporary org-mode buffer for parsing. Then org-element would be available. >=20 >> The babel feature is compelling to me (and I guess Chuck) on its >> own. It=E2=80=99s familiar (e.g. in the case of tables) that babel gets= to >> have its own data format for org elements. >=20 > It's the same for lists. Internal representation for lists should come > from "org-list.el", not from Babel. Internal representation for tables > comes from "org-table.el", too. Hmm. I had missed that, you are correct. >=20 >> I=E2=80=99m happy to undertake the above-described demolition job on >> org-list-parse-list in order to offset the added complexity from the >> babel change (we can call it a cap-and-trade system). But given that >> org-list-parse-list is a marginal part of the code base and perhaps >> moribund in the era of org-element >=20 > I don't consider radio lists moribund. Are they? 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 years of messages from the list: . I=E2=80=99m not advocating their removal or deprecation, but they certainly= seem like the tail and not the dog when considering what parts of org ought to wag what others. (I=E2=80=99d hope their usefulness would eventually naturally wane as org becomes compelling enough that people commit to it wholesale, rather than relying just on the list editing features while living in another document composition regime. Whether it=E2=80=99s worth keeping them around as a sort of training wheels I don=E2=80=99t really have an opinion on.) >=20 >> I don=E2=80=99t really think it=E2=80=99s worth it (to me) to try and en= gineer an >> improvement to it in order to enable the babel feature. >=20 > It is not (or should not be) a Babel feature. >=20 > Anyway, it's not about rewriting `org-list-parse-list', but if Babel > understands a new representation for plain lists, this function should > be able to generate it and `org-list-to-generic' should be able to > interpret it. Why? Babel=E2=80=99s representation is for babel. 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 forbidd= en 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.). >=20 > Could you detail the exact specifications of the suggested internal > plain list representation? I dunno if I=E2=80=99d call my proposal an =E2=80=9Cinternal plain list rep= resentation,=E2=80=9D but rather =E2=80=9Cbabel=E2=80=99s interpretation of plain lists.=E2=80=9D 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 th= ey 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: #+name: data - foo - bar - baz - quux - abc #+begin_src emacs-lisp :var data=3Ddata (pp-to-string data) #+end_src #+RESULTS: : ("foo" "bar" "abc") --=20 Aaron Ecay