On Sun, Jun 08 2025, Ihor Radchenko wrote: > "Martin Edström" <meedst...@runbox.eu> writes: > >> I'll conclude a yes on the feasibility analysis. I do wonder if it'd >> make sense for Org itself to have such an API (think a thin wrapper >> around org-element-parse-buffer results), because then org-agenda / >> org-ql / etc could be rewritten to make use of it, solving their perf >> issues no matter how many files you feed in. > > Sure. > Here is one of the long-term projects I have: > > ******* SOMEDAY #project org-query: Query interface for Org mode > :COMMON:emacs:project:SOMEDAY: > :PROPERTIES: > :CREATED: [2022-04-24 Sun 14:32] > :ORG-TIME-BALANCE-MULTIPLIER: -1 > :CATEGORY: OrgQuery[P] > :END: > :LOGBOOK: > - Refiled on [2024-04-26 Fri 15:37] > - Refiled on [2022-04-24 Sun 14:35] > CLOCK: [2022-04-24 Sun 14:32]--[2022-04-24 Sun 14:34] => 0:02 > :END: > # A short summary about the project. > #org_query #oq > Inspired by [[id:Github_alphapapaalphap_org_ql_org_mode1ed][alphapapa > [Github] alphapapa/org-ql: An Org-mode query language, including search > commands and saved views]] > > The idea is to provide centralised caching interface to query org buffers > quickly > > 1. Sexp-based quries > 2. Query caching > 3. Use org-element cache + regex search > 4. Allow multiple backends (think of org-roam) > 5. Provide better query language (similar to non-sexp org-ql)
Is there a necessity for org-element’s cache to be sparse? Is it mostly to avoid having to parse entire buffers (or at least large chunks of them) when they change? When I first heard about org’s caching, I had the (extremely) naive question of what technical reasons there are to not just store entire parse trees in a cache, even an on-disk one. -- Kind regards, Kristoffer
