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: Fri, 19 Jun 2020 22:28:39 +0300
> 
> > I'm not sure that the doc string will have to be changed (or how) when
> > you fix that, but that's a separate issue.
> 
> The fix would look like this:

So all you want to add to the current doc string is "...and doesn't
belong to some other project"?

> > But the default-directory of these buffers is a very weak evidence of
> > them being relevant to some project.  E.g., I could (and many times
> > do) grep some other project when I need to see how it solves some
> > problem which is relevant to what I'm working on now.
> 
> That is a case of working on multiple projects at once.

No, it isn't.  I'm working on a single project, but need to look
outside of its directory to find some information.  A very natural
thing to do, and it doesn't mean I started working on another
project.  More importantly, I do want that Grep buffer be available to
me as part of the current project, because I'm likely to return there
more than once.

> And whatever your purpose of grepping it, wouldn't you agree that
> that grep buffer is probably closer to the "other" project rather
> that to the current one?

No.  And that "other" project doesn't even have to be a "project" in
the project.el sense of the word.

> To reuse your argument, 'M-x switch-to-buffer' is still available for 
> borderline cases.

An argument that you dismissed previously.

> > If we really
> > want to record in these buffers what project they are related to, we
> > need to have stronger evidence, like what was the current-buffer when
> > the command was invoked, or maybe something else (like name the
> > buffers in some special way).
> 
> We would start with strong counter-examples.

I just gave you one.  You want to dismiss it as "not strong", but I
think you are making a mistake.  Search-like activities are
ubiquitous, and not confined to the project's directory tree.

I think that non file-visiting buffers are rarely related to a
project, an exception rather than a rule.  My suggestion is therefore
to turn the table and come up with a list of such buffers that
_always_ are related to a specific project.  And instead of using the
default-directory as evidence for the buffer's relevance, we may need
a command that explicitly makes a buffer related to a project.

> So default-directory is not the worst indicator.

I'm saying it isn't the best, either.  We have just discovered at
least 2 problems with it.  We should try to find a better one.

> But we should also try the new command out and document our experiences.

IMNSHO, some thought is required even before we hope the experience
will teach us in due time.  Doing this only by trial and error runs
the risk of converging on a design that is found later to be
restrictive, or one that cannot be easily extended to support
behaviors not accounted for or envisioned originally.

We are just at the beginning of development here, and so this is the
right place for thinking about possible project-related activities,
and how they could be supported by different ways of determining which
buffers are related to a project and which aren't.  A simple solution
we decide on now could make future development and extension much
easier.

> > That's fine, but Andrii's opinion is not the only one that counts, is
> > it?
> 
> So far Theodor agreed too. And myself as well. You alone have voiced 
> disagreement. With this distribution of votes, it seems the default 
> behavior should default to including non-file-visiting buffers (with 
> some agreed-upon exceptions).

For an opinion to "count", it doesn't have to _replace_ the other
opinions.  It could be taken into consideration by augmenting the
design so that it supports both kinds of behaviors.  This is IME
better than flatly discarding the dissenting opinions.

> And, of course, we can add a user option that would allow to tweak
> the choosing logic.

Sub-optimal selection of the "belongs to a project" criteria will make
any such user options cumbersome and hard to use.  IOW, user options
shouldn't be considered as means to "fix" sub-optimal design.  We are
at a point where we can make the design better, if we consider a wider
variety of project-related activities.