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

[Dmitry Gutov <dgutov@yandex.ru>]

On 04.07.2020 10:15, Eli Zaretskii wrote:

>> ...and I asked for design suggestions that would make the behavior
>> better from your standpoint.
> 
> 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'?

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. Fetching the current project of all those at once could result in 
a long pause (some benchmarking on various machines/project 
configurations/sessioning habits would be welcome).

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

>> 1. We can call 'project-current' in every buffer, and then compare the
>> returned values (this is what that alternative patch did). But recalling
>> bug#41029, it seems some users can have outstanding numbers of buffers
>> open, and this approach might heavily limit the performance of
>> project-switch-to-buffer, unless we employ some very heavy
>> buffer->project caching. And I'd really like to stay away from manual
>> cache invalidation.
>>
>> 2. We could call 'project-files' on the current project and compare the
>> values of buffer-file-name of every buffer. This could become slow with
>> larger projects. And the complexity will be N^2 (at least with naive
>> implementation), so it can be worse than project-find-file for those
>> projects. Also, this doesn't solve your problem with Grep buffers. But
>> it would help in the situation of having a project contain arbitrary
>> files from arbitrary directories.
>>
>> 3. Create a new generic function (or several) which would delegate the
>> inclusion logic to individual project backends. This would require work
>> on naming, semantics, what have you, and would likely still come out
>> clunkier than either of the previous two options.
> 
> #3 sounds like the best alternative to me, if a simple buffer-local
> variable doesn't do the job for some reason.

>> Further, with this approach, I'm still not sure of a good "fast"
>> solution for project-vc which leads to correct behavior in the
>> presence of nested projects.
> 
> 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. That's the situation 
when all of the files belong to a directory _except_ those that belong 
to projects inside the current one. Like the monorepo example Theodor 
described.

>>> When I do switch, I don't want to lose the "payload" of the project I
>>> switch from: its files, its Grep, XREF, and Compilation buffers, its
>>> documentation buffers, etc. -- because I know I will come back there
>>> in hours or days.  This means each project should stay readily
>>> accessible, so that I could pick up where I left off.
>>>
>>> It is true that the last Grep buffer I created most probably belongs
>>> to the current project, but that doesn't mean I want to give up the
>>> previous Grep buffer -- I might need it shortly.
>>
>> 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 would imagine that with such approach, using commands scoped to the 
current project's buffer would be more necessary.

Having said all that, I've had a couple more ideas for transparent 
caching, such as caching by default-directory in the project-vc backend, 
and clearing the cache in post-command-hook.

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.

N.B.: project-vc currently caches the "current project" info more 
persistently than would be ideal; a part of this experiment will be 
scaling back on that caching, and wait for complaints about performance.