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

[Eli Zaretskii]

> Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 5 Jul 2020 22:45:19 +0300
> 
> >> - 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.

I don't see how this would happen.  But we can cross that bridge if we
ever get to it.

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

I didn't say anything about a need for such a knob.  You are probably
misinterpreting what I wrote above.

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

Then why are we still arguing?

> Though it will also only scale up to a certain number of
> buffers/directories.

I think you are wrong when you fear this scalability problem; I don't
think it exists.