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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Eli,

On 29.06.2020 17:50, Eli Zaretskii wrote:

> I didn't mean to ask you to change your priorities.  I was only
> talking about the design of deciding what buffers belong to which
> project, and the implications of that design.

If you recall, I even posted a "more correct" patch a while back that 
wouldn't make the choice of which buffers belong to the project depend 
solely on the value of default-directory.

>> I think it's an objective summary. Because you said that not having this
>> capability keeps Emacs at a severe disadvantage to other editors. So it
>> was clearly a subject that required analysis.
> 
> 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.

Some ideas, old and new:

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

>> The model that other editors use, and the one I'm assuming you do as
>> well (guessing mostly due to how tags' UI works), is that you work only
>> on one "project" (in your sense of the word) at a time.
>>
>> Then, would I be correct to assume that if there exists a Grep buffer in
>> the current session, then it mostly likely belongs to the current
>> "project"? If so, would there be any particular advantage to using
>> project-switch-to-buffer instead of plain switch-to-buffer?
> 
> No and no.  My Emacs sessions run for many days on end, and during
> that time I work on several projects.  Sometimes I need to switch
> between them every few minutes (e.g., when I read my email and need to
> answer questions and request, or review code, related to several
> projects, in the order in which I read the incoming email).  More
> often, I would work for several hours on one project, then switch to
> another, then to yet another or back to the first.

I see, thank you.

> 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 way, they wouldn't be "lost", but you'd have to deal with filtering 
through many buffers. Even so, Grep buffers are usually named uniquely, 
so it's unlikely to be a total disaster. And you wouldn't be able to 
clean then up easily with project-kill-buffers.

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

>> I never said that it's an ideal method. And I'm sure there can be
>> problematic examples out there. But I wasn't convinced by the example
>> you gave because the reason for why it was bad was based on your
>> understanding on the word "project", and not on mine. Thus, it's hard
>> for me to choose a good solution for the project backend which is based
>> on my understanding of the word "project".
> 
> I'm not asking you to come up with a backend suitable for the use case
> I described.  I'm asking you to take that use case into consideration
> when you design the means of deciding which buffer belongs to what
> project.  If we design this decision in a way that cannot be easily
> extended to reasonable use cases we can envision, we will limit
> ourselves in the use cases we can usefully support, ever.  Let's try
> to avoid producing such a restrictive design, if we can.

Sure, agreed.