On 13/08/2024 16:31, Ship Mints wrote:
> A good step is awareness for users and invalidating the cache via 
> project-forget methods is a good idea. 

For posterity: making it a method of an object doesn't seem to work 
since the directory might have changed enough that it's not possible to 
recreate the project instance to call it on.

 > I'd also offer a direct function
 > to invoke to invalidate the cache for programmatic use.

project-forget-project is a Lisp function which could be used both 
interactively and from code. Attached is a PoC/WIP patch which adds 
cache invalidation this way. Not entirely happy with the approach yet, 
but I'd like to checkpoint it here.

> vc caching, longer term, may need to consider a few more complex use 
> cases such as git repos with both submodules that are considered 
> extensions of the base project and submodules which are not. A concrete 
> example I see often is a "mono repo" structure with core server and 
> library code but with web and mobile front end code in submodules that 
> are treated as part of the project proper BUT with submodules for 
> vendor/third-party code that are not. A question here would be which 
> parts of the tree belong to which cached vc root.

Very tangentially, we've just added support for speeding up file listing 
for projects using "sparse index". That one's for a different structure 
and repos above certain size, though.

> Another use case I see is working on many unrelated projects/repos 
> across a variety of clients all in the same Emacs session and with 
> perhaps 100+ buffers/files open (as I pretty much have right now), a 17- 
> element cache won't be sufficient? Should the cache be for parent 
> directories and not for file names? With files, it gets full fast. Mine 
> is full right now with files most of which share the same repo root and 
> some that don't.

These are all internal details, but:

* 17 is the default size, then it grows,
* project-try-vc caches only directories, using its own key,
* The rest of the data you're seeing is for files and their VC statuses, 
that's separate info.

But indeed it's a bit too much intermixing, project-vc's cache should 
move to its own structure first. Stay tuned.

> I have wondered whether an implementation would be 
> better as directory variables? Cache invalidation without timestamps 
> on .dir-locals.el files remain the same but directory variable treatment 
> might be more natural to Emacs users?

Directory variables are a thing, but not in the same sense that 
file-local variables are, in particular there is no object to save a 
"directory local" to at runtime.