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: Thu, 2 Jul 2020 01:57:37 +0300
> 
> > Once again, my problem is not with the schedule of providing the
> > support for the use case I described, but with the current design
> > which AFAICT makes it hard to add such support in the future.  We
> > should modify the design to make such use cases easier to add.
> 
> ...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?

> 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, or a directory if all the files in the directory belong
to the project.

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

> Anyway, I'm talking about the backup plan here. One to consider if we 
> don't manage to settle on a better approach.

Understood.