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: Wed, 24 Sep 2014 21:56:36 +0200 Message-ID: <87tx3weqrv.fsf@nicolasgoaziou.fr> References: <87ha03qv19.fsf@gmail.com> <87ha02a4qg.fsf@nicolasgoaziou.fr> <87d2anougv.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]:44948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWsfc-00016E-B9 for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 15:56:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWsfS-0001wZ-6f for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 15:56:12 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:46047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWsfR-0001w8-UR for emacs-orgmode@gnu.org; Wed, 24 Sep 2014 15:56:02 -0400 Received: from mfilter29-d.gandi.net (mfilter29-d.gandi.net [217.70.178.160]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 3398F172081 for ; Wed, 24 Sep 2014 21:55:52 +0200 (CEST) Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter29-d.gandi.net (mfilter29-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id T482nc2zPwJV for ; Wed, 24 Sep 2014 21:55:50 +0200 (CEST) Received: from selenimh (unknown [91.224.148.150]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id A0541172071 for ; Wed, 24 Sep 2014 21:55:50 +0200 (CEST) In-Reply-To: <87d2anougv.fsf@gmail.com> (Aaron Ecay's message of "Tue, 23 Sep 2014 00:02:08 -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: > I think I can remove these three functions (-parse-list, -to-subtree, > and -to-generic), and rewrite their callers to use org-element. Thus, > the org-list-parse-list format would be eradicated from the code base > incl. contrib (AFAICT). Can I do that, or do I need to care about > preserving backwards compatibility with external callers of these > functions? If backwards compatibility must be preserved, may I mark > these functions as deprecated and what is the minimum period (measured > in calendar time and/or org versions) that should pass before their > removal? You cannot do that. This is not about backwards compatibility. `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). `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. 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). 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. > 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. 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. > 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 I don't consider radio lists moribund. Are they? > I don=E2=80=99t really think it=E2=80=99s worth it (to me) to try and eng= ineer an > improvement to it in order to enable the babel feature. It is not (or should not be) a Babel feature. 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. Could you detail the exact specifications of the suggested internal plain list representation? Regards, --=20 Nicolas Goaziou