From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Lexical binding bug in org-list.el? Date: Sat, 07 Nov 2015 11:54:44 +0000 Message-ID: <87r3k2t46z.fsf@gmail.com> References: <87wptuua9n.fsf@gmail.com> <87ziyq7j8t.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]:35728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv255-0003v7-Ex for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 06:54:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zv252-0005Ik-7q for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 06:54:51 -0500 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:38636) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zv251-0005Ig-VY for emacs-orgmode@gnu.org; Sat, 07 Nov 2015 06:54:48 -0500 Received: by wicll6 with SMTP id ll6so42520888wic.1 for ; Sat, 07 Nov 2015 03:54:47 -0800 (PST) In-Reply-To: <87ziyq7j8t.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 , Kaushal Modi Cc: emacs-org list Hi Nicolas, 2015ko azaroak 7an, Nicolas Goaziou-ek idatzi zuen: >=20 > Hello, >=20 > Aaron Ecay writes: >=20 >> The org-list code is a mess, and I think we should hold off on converting >> it to lexical scoping until it can be refactored in a more dedicated >> way. >=20 > It seems a bit strong considering there's only one issue so far. I don't > think the code is a mess, but "Send and receive lists" part clearly > needs an overhaul. >=20 >> Nonetheless I include the patch, in case it=E2=80=99s helpful to anyone. >=20 > Lifting `org-list--get-text', `org-list--parse-item', etc. isn't > necessary.=20 I=E2=80=99ll defer to your judgment, of course, especially where it comes to fixing the immediate issue. 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 outside= 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. 2. It=E2=80=99s impossible to unit test the small let-bound functions. In view of this, do you think it would be desirable in the long term to refactor code like this into top-level functions? > I just forgot a `letrec' in `org-list-parse-list'. Oh ok. I had never seen letrec before these recent lexical binding changes, so I wasn=E2=80=99t familiar with how it could fix the problems. = But I=E2=80=99m glad it can. > [...] I originally wrote individual responses to the points in the rest of your email, but then I realized that it=E2=80=99s slightly more than a year since we had an eerily similar discussion: . I don=E2=80=99t think we reached any conclusion then. To avoid the same thing happening, I=E2=80=99m going to try to step back and sketch the vision I have about this code from a high-level perspective. 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 replaced 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 You said: > Actually, `org-list-to-generic' in its current form isn't adequate for > anything. Even `org-list-to-*' functions do not use it. And > we can re-implement `org-list-to-subtree' without using > `org-list-to-generic'. Which I think means we are on more or less the same page about org-list-to-generic. You also said: > `org-list-parse-list' should be simplified, too, as its current return > value is useless (e.g., nothing uses [CBON] anymore in the code base). Here I=E2=80=99m more radical than you: since the current return value is u= seless (I agree) and hardly used anywhere, my conclusion is to just get rid of the function, rather than trying to invent a way in which it could be useful. I hope that having laid it out in this way helps to understand what I have in mind. I=E2=80=99d of course be very glad to hear what your thoughts are, and hopefully we=E2=80=99ll be able to work out how to proceed. --=20 Aaron Ecay