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

[Eli Zaretskii]

> Cc: philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 20 Jun 2020 14:29:20 +0300
> 
> On 20.06.2020 11:55, Eli Zaretskii wrote:
> > I proposed to find a different way of telling which buffer is related
> > to a project, other than by looking at its default-directory.  We
> > could design a way of doing that which would then support adding
> > buffers to a project quite easily.  But Dmitry doesn't think we should
> > go that way.
> 
> If you can outline and propose that alternative way, I'm all for 
> considering it.

I think I did.

And I don't really understand what is being requested here.  Recording
something in a variable, be it a buffer-local one or a global one
indexed by a project, is easy, and doesn't require any complicated
design.  I'm talking as a user here, asking you to support what I
think is a very common usage pattern of working on some programming
problem that involves changes in a group of related files.

> Compared to an ad-hoc variable (or having a command that adds such a 
> buffer manually), I'd much prefer an automatic approach.

Not sure what does "automatic" mean here.  If that means using only
currently available buffer-local variables, then who's to say that
this is good enough?  Why limit ourselves to only such solutions?  the
few presented examples already uncovered some deficiencies in relying
on one such variable.

OTOH, we could introduce a new buffer-local variable to be
automatically set by, say, a find-file-hook, or by project-find-file,
or via some other feature we have.  Same with recording relevant
buffers in some project-specific data structure.

IOW, it sounds like we have any number of ways for doing something
like that, and the only argument is whether we should.