emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: org-mode functional programming library


From: Nicolas Goaziou
Subject: Re: org-mode functional programming library
Date: Sat, 01 Feb 2020 14:53:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello,

"Dwarshuis, Nathan J" <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]