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: Mon, 29 Jun 2020 01:35:19 +0300
> 
> >> Not to discourage alternative workflows, but this is the concept we
> >> should work on supporting well first.
> > 
> > What do you mean "first"?
> 
> Meaning, I have to prioritize the tasks in my personal queue. And there 
> are other features I should get to as well. I hope you'll like them 
> either way.

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.

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

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

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.

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

I can understand why some design might not be conducive to supporting
use cases we never thought could be relevant.  But this use case we
already envision, and unless you really think it's completely not
relevant, the design should IMO be able to support it easily enough.