From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: org-mode functional programming library Date: Sat, 01 Feb 2020 14:53:43 +0100 Message-ID: <87o8uict20.fsf@nicolasgoaziou.fr> References: <87o8uxellj.fsf@yavin4.ch> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47510) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixtDh-0006za-1u for emacs-orgmode@gnu.org; Sat, 01 Feb 2020 08:53:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ixtDf-000591-As for emacs-orgmode@gnu.org; Sat, 01 Feb 2020 08:53:56 -0500 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:37109) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ixtDf-0004zt-4r for emacs-orgmode@gnu.org; Sat, 01 Feb 2020 08:53:55 -0500 In-Reply-To: <87o8uxellj.fsf@yavin4.ch> (Nathan J. Dwarshuis's message of "Mon, 20 Jan 2020 18:47:52 -0500") 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-mx.org@gnu.org Sender: "Emacs-orgmode" To: "Dwarshuis, Nathan J" Cc: Emacs Org Mode mailing list Hello, "Dwarshuis, Nathan J" writes: > I recently authored an package called "om.el" which is a functional > org-mode API akin to dash.el primarily using org-element. Briefly, it > provides a library of (mostly) pure functions that manipulate the > parse tree generated by org-element.el, and uses this to either edit > or query the buffer with all the advantages of functional programming > (eg lack of side effects, referential transparency, easier testing, > etc). The github repo for om.el is here: > https://github.com/ndwarshuis/om.el. > > I'm posting to the mailing list a) for general feedback on this > package and b) because I am wondering if this would be a good package > to include with org-mode itself rather than in another repository such > as MELPA. The code for om.el is tightly integrated with org-element.el > and it might make sense for development between these to be closely > intertwined. Thank you for this thorough work. Note that code going into Org proper cannot rely on external libraries, e.g., "s.el" or "dash.el". So it may make sense to integrate it, but not in its current form. Is it possible to write it without these libraries, and without re-inventing the wheel? Note that, at some point, Org will support "seq.el", i.e., when we drop support for Emacs 24. Skimming through your code, I read a lot of griefs against Element library (inconvenient, unfortunate, buggy, inconsistent... I stopped there). I agree on most points, of course. Though, there are a few cases where you seem to miss the point. Also, the way you handle plain lists is not how it is done in Org. Anyway, it could be beneficial for both Org and your library to discuss the points above and improve the parser. WDYT? I didn't check, but how do you alter the buffer when applying changes to the parse tree? Is it optimized, e.g., only changed lines are replaced? Or are you deleting the whole thing and replacing it with the interpreted stuff? Note that Org has hardly ever access to the full parse-tree, because parsing a whole buffer is too slow. So, because of these limitations, I wonder if your library can be used efficiently to alter the buffer. Regards, -- Nicolas Goaziou