[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 1e3b0f2: Improve doc strings of project.el

From: Dmitry Gutov
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Sun, 5 Jul 2020 22:45:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 05.07.2020 17:26, Eli Zaretskii wrote:

The problems I can see with that are:

- Since project is not a minor mode, we don't call it in major mode
hooks. Which, by itself, is probably a good thing (causing no
unnecessary work/slowdown). But that means that in the middle of any
session we could have 100s of buffers that don't have any cached project

We have project-find-file and other similar project-* commands that
could cache that as side effect.

That would still potentially leave hundreds of buffers in which said commands have never been used.

- A project configuration can change mid-session (due to a customization
of some user option, or due to an edit in some .dir-locals.el). Or
simply due to 'git init'. As a result, a given file's current project
can change. It will be good to be able to support that without
necessitating Emacs' restart or requiring manual cache invalidation.

I don't see how you can avoid some user command which would mean a
project configuration change.  Alternatively, this could be solved
lazily, when the cached value is found to be outdated.

Speaking of standards set by other editors, have you ever seen an IDE with an "invalidate project cache" button? I haven't.

Luckily, in the common configuration we can rely on 'git ls-files' to be pretty fast, though that will only handle projects up to certain size.

I was thinking filenotify could help us with cache invalidation, but past discussions have left an impression that we can't fully rely on it either.

We don't need to solve every possible complication up front before we
decide that a method is workable, we just need to have a vague idea
how it could be solved when the time comes.

As mentioned, I have that "vague idea" now. Though it will also only scale up to a certain number of buffers/directories.

or a directory if all the files in the directory belong
to the project.

The problem is in the case of *nested* projects.

The first part above should take care of that.  The second part was to
suggest a shortcut: let a directory stand for all the files in it.

For its direct contents, but not subdirectories? Yes, that's what I was thinking of as well.

Anyway, the current version of code should support your and Stephen's kinds of projects. Someone can try experimenting with writing the backend now.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]