Well-explained! Thank you, Kristoffer :) On Mon, 26 May 2025 16:02:30 -0500, Kristoffer Balintona <krisbalint...@gmail.com> wrote:
> On Mon, May 26, 2025 at 12:02 PM chris <inkbottle...@gmail.com> wrote: > > > Org-node seems very interesting! I noticed that your [parser.el](https:// > > github.com/meedstrom/org-mem/blob/main/org-mem-parser.el) is only about 600 > > lines long, whereas Org-mode’s parser seems larger and possibly more > > scattered? Are they roughly equivalent in scope/intent, or is your version > > focused on a different subset of Org features? > > Hi, > > I am not Martin, but I’ll share a bit about what I’ve gathered about the > project after having used org-node for a few months. > > As far as I can tell, the org-mem parser is a parser specially tailored > for a specific end, namely, speed. What sets org-node apart from > org-roam is that it does not need anything on-disk; it maintains hash > tables inside Emacs for all its data. (Additionally, and in line with > org-node’s mission for performance, it does not end up needing to load > org at all, since its parser is an implementation independent of it.) It > can get away with this because the parser is very fast and leverage’s > el-job’s[1] asynchronous processing of lists. > > Of course, the trade off for parsing speed is completeness: org-mem must > implement its own regexps to find the data it needs. Everything else is > ignored. So if org-mem wants to collect e.g. timestamp data, it must do > so without any help from org (as was recently implemented). Org also > does a lot to process things like org keywords in files. And, of course, > this approach is susceptible to mismatches with what org’s parser > actually recognizes since org-mem’s parser is bespoke. > > I’m guessing part of Martin’s motivation to ask his original question is > related to how tenable maintaining a parser independent from org is. It > would be much easier to rely on the definitive org parser if possible. And > if I would speculate further, I think what he has in mind is to store > the parse trees on disk and read from those (potentially caching those > on-disk parse trees if necessary) rather than the user’s files. This way, > performance is still fast since the user’s org files are already parsed > (which is the expensive part). > > Martin can chime in and share to correct me if I’m wrong. > > -- > Kind regards, > Kristoffer
