From dcad551760b285e54b4fad3ec626f9283289b22f Mon Sep 17 00:00:00 2001 From: Adam Porter Date: Thu, 5 Sep 2019 12:39:23 -0500 Subject: [PATCH] Notes: Add on node caching --- notes.org | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/notes.org b/notes.org index 1cc3133..fef7fac 100644 --- a/notes.org +++ b/notes.org @@ -281,6 +281,14 @@ With caching, the search doesn't need to be repeated, so resorting/regrouping ca When tag inheritance is enabled, and the given tags aren't file-level tags, we could search directly to headings containing the matching tags, and then only do per-heading matching on the subtrees. Sometimes that would be much faster. However, that might make the logic special-cased and complicated. Might need a redesign of the whole matching/predicate system to do cleanly. +** MAYBE "Node" caching + +[2019-09-05 Thu 12:30] At each node checked by a predicate, make a struct that stores attributes we can query for, as well as parent node position. This would let us speed up ancestor-based queries, like =(ancestor (todo "WAITING"))=. Ideally it would also serve as the tag hierarchy cache. + +It would probably be an all-encompassing system, because predicates would need to refer to the cached node when available. So maybe the struct should be like =ts-defstruct=, with lazy, caching accessors, which would move some of the predicates' code into the accessors. + +Maybe a good improvement to make later, after the project is more developed. + ** MAYBE Implement view with tabulated-list-mode or magit-section [2019-09-02 Mon 05:20] Especially with some of the new packages that make =tabulated-list-mode= easier to use, like =navigel=. However, it would probably break grouping, or require some kind of adapter or extension to do grouping, so I don't know if that would work. Something like =magit-section= would be more flexible, and could be recursively grouped, like in =magit-todos=.