Hello Nicolas, thank you for the reply > 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.
It would be possible but would obviously require some work but would be doable. I will say that there's a macro I am hoping to add to dash that implements &rest and &key simultaneously (impossible with 'cl-defun') so if this package doesn't depend on dash that might be reinventing the wheel (assuming it gets in). > 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? My apologies if this came across as rude; I can be quite blunt in my comments. Anyways, I would definitely like to discuss further how we can improve both. Do you mind elaborating on how plain-lists are handled differently between Org and this library. Also, just so we are on the same page, where do I seem to miss the point? > 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. This is actually a place where I would like feedback. The function you are probably looking for is 'om-update' (and related) which parses all/part of the buffer to a parse tree, transforms it in some way, then writes it back. There is also 'om-insert' which just inserts a parse tree created from scratch. I wouldn't call it optimized, but I designed the update functions to parse as little as possible to only get the relevant parse tree. Eg if you only care about one headline, there is the function 'om-update-headline' which parses only within the boundaries of that headline. That being said, the limitations of this are that it doesn't get the :parent property (unless you actually parse the parent as well) and it replaces the entire parse tree (as opposed to only replacing the lines that are changed) which automatically deletes the overlays that allow folding. To deal with the latter I have 'om-fold' and 'om-unfold' but these aren't the most convenient and it would be much easier all-around if the write-back operation only replaced what changed (currently on my todo list). I also wonder if there is a way to control what is being parsed, as some elements can be fully represented with only a subset of their properties. ________________________________ From: Nicolas Goaziou <m...@nicolasgoaziou.fr> Sent: 2020-02-01T08:53:43-0500 To: Dwarshuis, Nathan J Subject: org-mode functional programming library Hello, "Dwarshuis, Nathan J" <nd...@yavin4.ch> 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,
