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: Tue, 23 Sep 2014 00:02:08 -0400 Message-ID: <87d2anougv.fsf@gmail.com> References: <87ha03qv19.fsf@gmail.com> <87ha02a4qg.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]:53199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWHJ5-0002sG-2P for emacs-orgmode@gnu.org; Tue, 23 Sep 2014 00:02:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWHIu-0002cN-Nz for emacs-orgmode@gnu.org; Tue, 23 Sep 2014 00:02:26 -0400 Received: from mail-qc0-x229.google.com ([2607:f8b0:400d:c01::229]:37525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWHIu-0002aA-Jh for emacs-orgmode@gnu.org; Tue, 23 Sep 2014 00:02:16 -0400 Received: by mail-qc0-f169.google.com with SMTP id x3so1222137qcv.14 for ; Mon, 22 Sep 2014 21:02:11 -0700 (PDT) In-Reply-To: <87ha02a4qg.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 your feedback. 2014ko irailak 20an, Nicolas Goaziou-ek idatzi zuen: >=20 > The problem I see here is that you're introducing yet another internal > representation for lists (along with element's and > org-list-parse-list's). Worse, it can only be discovered when reading > the docstring of a Babel internal function and will only benefit to > Babel. >=20 > If this new internal representation is better than current one, by all > means, improve `org-list-parse-list', and document it in >=20 > (info "(org) Radio lists") >=20 > This is more work, but, IMO, it is also the only sane way to proceed. Indeed. The internals of org-list are not pretty. org-list-parse-list has few callers: - org-list-make-subtree - org-babel-read-list - org-toggle-heading org-list-to-subtree has only two callers: - org-list-make-subtree - org-toggle-heading org-list-to-generic also has only two callers: - org-babel-insert-result - org-list-to-subtree 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? 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. 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 =E2=80=93 and perhaps moribund in the era of org-element =E2=80=93 I don=E2=80=99t really think it=E2=80=99s worth it (t= o me) to try and engineer an improvement to it in order to enable the babel feature. WDYT? --=20 Aaron Ecay