From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Lexical binding bug in org-list.el? Date: Sun, 08 Nov 2015 15:57:20 +0100 Message-ID: <878u688rov.fsf@nicolasgoaziou.fr> References: <87wptuua9n.fsf@gmail.com> <87ziyq7j8t.fsf@nicolasgoaziou.fr> <87r3k2t46z.fsf@gmail.com> <87twox92nx.fsf@nicolasgoaziou.fr> <87a8qpts31.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]:53106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvRNZ-00082h-9A for emacs-orgmode@gnu.org; Sun, 08 Nov 2015 09:55:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZvRNY-0004rI-4H for emacs-orgmode@gnu.org; Sun, 08 Nov 2015 09:55:37 -0500 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:47856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZvRNX-0004rE-MY for emacs-orgmode@gnu.org; Sun, 08 Nov 2015 09:55:36 -0500 Received: from selenimh (unknown [IPv6:2a01:6600:8080:9601::2de]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 1042CA80B0 for ; Sun, 8 Nov 2015 15:55:34 +0100 (CET) In-Reply-To: <87a8qpts31.fsf@gmail.com> (Aaron Ecay's message of "Sat, 07 Nov 2015 21:30:58 +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: emacs-org list Aaron Ecay writes: > I don=E2=80=99t think we should unit-test only public API functions. I didn't say that. However, I wouldn't write tests for "--" functions. > Indeed, I find it easier to write unit tests for small functions, > since I don=E2=80=99t have to construct a lot of extra context to exercis= e all > the corner cases. That's not my point. However I'd rather spent my time elsewhere than writing tests for worker 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? >>=20 >> No, I don't. I see no reason to pollute name space with these very >> specific functions. > > I=E2=80=99m not sure I get it =E2=80=93 interned symbols are cheap, and w= ith the new-ish > double-dash convention for private functions users/downstream developers > can be pretty sure they don=E2=80=99t need to worry about them. I see no reason to define at top level a worker function with a very limited scope. Much like let bindings I find it much clearer to keep the scope of a function as close as possible to its real use, as long as the function isn't too large. If one day, it is deemed useful in another function, then it can be lifted to top level. Anyway, this we're really nitpicking. There's nothing fundamentally wrong in either choice. >> - change `org-list-parse-list' to provide a simpler output and update >> Babel should to use that new output. So the new output could be plain-list =3D (type item+) type =3D ordered | unordered | descriptive item =3D ((text|plain-list)+) Thus, 1. first item + sub-item one + [X] sub-item two more text in first item 2. [@3] last item is parsed as (ordered ("first item" (unordered ("sub-item one") ("[X] sub-item two")) "more text in first item") ("[@3] last item")) The slightly tricky part is taking care of the indentation when text contains more than one line. Also, for completeness, a descriptive list, e.g., - tag :: text would be simply parsed as (descriptive ("tag :: text")) The objective is to make this syntax easy to create programmatically, e.g. for Babel. Making something out of it would be the goal of `org-list-to-generic'. WDYT? >> - re-implement `org-list-to-subtree' using directly Elements, or even >> string massaging. > > OK, these both sound do-able. Meanwhile, I fixed the current issue. It is as ugly as before, but at least, no error is thrown anymore. >> - 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'. Having slept over the idea, I think we could simply update `org-list-to-generic' to be more robust and be done with it. I can implement it in a couple of hours (and debug it in a couple of months...). Regards,