Store coupling file info on disk about code-compass

[ag91]

What is your use case? For example what command are you using? Currently it caches in memory with `code-compass-coupling-project-map` because I may have called the `code-compass-create-todos-from-coupled-files` function on the repository and didn't want to wait all that time. I didn't integrate that into the graphic analysis for coupling I think. Probably it is just a matter of integrating that caching with some sort of serialization, but I need to understand what are you trying to achieve.

…

On Thu 16 Feb 2023 at 11:18, Gopar ***@***.***> wrote: Would be nice to save a cached version of the coupling results. Thoughts: when calculating the coupling results it would be nice to take a snapshot of the current head commit and branch. Reasoning: * if head commit changes, then cached results might not be valid * Same reasoning for current branch * if we match on both of these, then retrieve results, otherwise re-calculate * We could save on directory {$code_compass_home}/.coupling_files/commit_hash ? ¯_(ツ)_/¯ Not sure if this makes sense or is too ambitious. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[gopar]

When I run code-compass-find-coupled-files it usually takes a good amount of time to finish. I tested out on smaller projects and it would finish pretty fast. I wouldn't want to wait multiple minutes every time i restart emacs, would rather have cache of some sort to read from disk if nothing has changed since last time.

[ag91]

that makes sense. It seems all we need is to serialize at this point https://github.com/ag91/code-compass/blob/main/code-compass.el#L896
with something like

(defun store-data (variable value)
  "Persist VARIABLE to given VALUE for the next session."
  (write-region (pp ??) nil "somfile")

That would serialize by project. The branch capabilities would need some extension, but probably that would be a good first step.
The other thing is to add an argument to reset this local cache, in case it is giving unexpected results. Probably also a message telling we are using a cached result would help users finding out why things may be surprising.
Would you like to give it a go? In my little free time, I am trying to get this to Melpa at the moment, so this may have to wait some time.