From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Lexical binding bug in org-list.el? Date: Sat, 07 Nov 2015 17:48:02 +0100 Message-ID: <87twox92nx.fsf@nicolasgoaziou.fr> References: <87wptuua9n.fsf@gmail.com> <87ziyq7j8t.fsf@nicolasgoaziou.fr> <87r3k2t46z.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]:35148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv6d9-0003Xv-1y for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 11:46:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv6d7-00082T-Vt for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 11:46:18 -0500 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:35429) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv6d7-00082J-Lv for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 11:46:17 -0500 In-Reply-To: <87r3k2t46z.fsf@gmail.com> (Aaron Ecay's message of "Sat, 07 Nov 2015 11:54:44 +0000") 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: Kaushal Modi Cc: emacs-org list Aaron Ecay writes: > On a broader scope, this is just one part of org that is written in this > style (one large let that defines many functions which call each other; > the body of the let is just a call into one of these functions). This > isn=E2=80=99t idiomatic elisp (at least, I=E2=80=99ve never seen it outsi= de org), and it > seems suboptimal for at least two reasons: > 1. The interface between the functions isn=E2=80=99t well-defined =E2=80= =93 they could > exchange information via arguments and/or by modifying variables > introduced by their containing let. They are mutually recursive functions. I don't think that is un-idiomatic in the Lisp world. I don't think why the reason above would make them sub-optimal, too. > 2. It=E2=80=99s impossible to unit test the small let-bound functions. Why would you want to unit test them? They are an implementation detail. Only `org-list-parse-list' should be tested here. > In view of this, do you think it would be desirable in the long term to > refactor code like this into top-level functions? No, I don't. I see no reason to pollute name space with these very specific functions. > If it was up to me, there would be only three kinds of code touching > lists in org: > - code that manipulates org-elements objects and (where necessary) > converts them to strings using the exporter > - a single function in ob-core that takes org-elements lists and converts > them into a simple nested list format, for use as input to babel code > blocks > - a single function in ob-core that is the inverse of the one above, for > processing the output of code blocks > > I think this implies: > - org-list-parse-list deprecated/removed > - org-list-to-generic deprecated/removed > - callers of these two functions updated to use org-elements/ox (with new > helper functions introduced for this purpose if it seems necessary) > > The simplicity gains from this would be: > - fewer functions in the public API of org (org-list-parse-list is replac= ed > by preexisting org-elements functions, and org-list-to-generic by ox > functions) > - hopefully less code to maintain (in terms of lines), though it remains > to be seen how much or if at all these changes actually shrink the > code base > - all org code manipulating lists uses a single format (org-elements). > Babel code blocks are not org code (and often not in elisp), so they > are the only thing that gets to use a different format > - the plist format controlling org-list-to-generic goes away Like for radio tables, radio lists are meant to be used in foreign buffers, i.e., buffers not in Org mode. They have almost the same requirements as Babel code blocks, which explains why they share the same representation. The same happens with radio tables, which provide their own representation to Babel, through `org-table-to-lisp'. If only for symmetry, Org List should be the provider of any list representation. Moreover, `org-table-to-generic' is a powerful and flexible thin wrapper around Org Export. In particular, `org-table-to-latex' is quite different from calling `org-latex-export-to-latex' on an Org list. Similarly, `org-list-to-generic' could be implemented as such, and, therefore, may not be discarded too easily. I'm not married to radio lists, and I wouldn't mind them being removed, but, if they are to be kept, they should at least be implemented correctly, not left in their current dumbed down state. Unfortunately, if I had to guess, I'd say that radio lists have no user, unlike to radio tables (which have their own video on a popular site). My take on the problem at hand is - change `org-list-parse-list' to provide a simpler output and update Babel should to use that new output. - re-implement `org-list-to-subtree' using directly Elements, or even string massaging. - start a poll on the ML to guess the potential user base for radio lists. Depending on the results, we might either deprecate the whole thing, as you suggest, or implement in a more powerful and clean way. Note that first item implies `org-list-to-generic' should be updated to handle new output for `org-list-parse-list'. Regards,