GNU bug report logs -
#72300
project.el: detect newly created project contained within another
Previous Next
Full log
Message #26 received at 72300 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[project-forget-functions.diff (text/x-patch, attachment)]
This bug report was last modified 264 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.