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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 5 Jul 2020 01:22:50 +0300
> 
> > I proposed one: have a special per-buffer variable which will give the
> > project (or a list of projects, if we want this to be more general) to
> > which the buffer is related.  I don't think we discussed that
> > possibility in detail, did we?
> 
> You mean like caching the return value of 'project-current'?

Something like that, yes.

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

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

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.

> > project-vc could then store the list of files in the project to serve
> > the request,
> 
> Store like cache the return value of 'project-files'? Still the same 
> issue with cache invalidation, described above.
> 
> > 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.

> >> What I meant, would there be a lot of downside to using switch-to-buffer
> >> specifically to switch to file-less buffers such as Grep when a need arises.
> > 
> > This would mean we give up on supporting this use case by project
> > commands, wouldn't it?  Then I'd ask why this case is unsupported,
> > while the one described by Andrii is?
> 
> Andrii's (and others') workflow implies more frequent switching between 
> "projects", rather than working on a single one for a long time.

I don't see how that matters.  We cannot/shouldn't prefer some valid
workflows to other valid workflows, we should try supporting all the
reasonable ones.

> So we can go ahead with idea #1 (which implies no hard change to the 
> API) and see how far we can get push this idea without manual cache 
> invalidation, while keeping decent performance for most of our users.

OK.