Rethink concept of cache hooks

[l3kn]

In the current version, cache-hooks are added using the org-el-cache-add-hook function.

This allows splitting hook definitions over multiple files / multiple sections of one file.

(def-org-el-cache
  file-selector-cache
  '("~/org")
  "~/org/.file-selector-cache.el")

(org-el-cache-add-hook
 file-selector-cache
 :title (lambda (filename el) ...))

An alternative would be to pass a plist of hooks to def-org-el-cache, which makes it easier to reason about which properties are available in the cache and future versions could detect if a new property has been added since the last time the cache has been persistet, then update it.

(def-org-el-cache
  file-selector-cache
  '("~/org")
  "~/org/.file-selector-cache.el"
  (list :title (lambda (filename el) ...)))

A further step would be to move the lambda outside the plist:

(def-org-el-cache
  file-selector-cache
  '("~/org")
  "~/org/.file-selector-cache.el"
  (lambda (filename el) (list :title ...)))

@jethrokuan, after checking the code, do you have an opinion on that?

[l3kn]

One place where this becomes interesting is when conditionally enabling features in https://github.com/l3kn/org-zettelkasten.

At the moment, I'm using two caches there, one without archives and one with org-archives.

Ideally, it should be possible to enable/require only a subset of the features, e.g. only cached file titles for the file selector but not cached links for the backlink view.

This would require a mechanism for conditionally adding properties to a cache akin to org-el-cache-add-hook.

[jethrokuan]

I would prefer the last, which is the most efficient and natural to me. For your concern of conditional addition of properties, I'd define a function like this:

(defun foo (filename el)
  (when title-enabled
     ; append title to plist
   )
  ...)

(def-org-el-cache
  file-selector-cache
  '("~/org")
  "~/org/.file-selector-cache.el"
  #'foo)

[l3kn]

Good idea, I like this a lot!

I've pushed a change replacing hooks with a single lambda, that makes the file-selector example much simpler.

[l3kn]

This also seems like the smallest interface that would be useful, everything else (e.g. a plist-hook mechanism) can be implemented on top of that.