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

[Dmitry Gutov <dgutov@yandex.ru>]

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
>> value.
> 
> 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.