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: Mon, 29 Jun 2020 01:14:36 +0300
> 
> As such, I'd rather let someone else implement the project backend with 
> the features you outlined. And if someone decides to take it up, I have 
> a number of thoughts on how it can be better integrated.

Implementing this, and the priority assigned to doing so, is not the
main issue that bothered me, and caused me to start this thread.  This
is a tangent; see below.

> OTOH, along the lines of Juri's opinion, perhaps your requirements could 
> be satisfied by making use of whitelisting entries in VC project config. 

Whitelisting is a nuisance when you need to whitelist too many files;
blacklisting is a nuisance when you need to blacklist too many files.
Other than that, both are fine.  But again, that's not the issue here.

> > I'm not talking in terms of backends, I'm talking in terms of
> > user-facing features.  I think we should decide whether a feature such
> > as the above should be part of what project.el supports, and then
> > consider how to implement it.  I don't see why the implementation
> > should be very complicated, FWIW, so there's no need to bring the
> > implementation into the picture, not yet.
> 
> A naive implementation should be pretty easy. What is difficult is 
> fitting this starkly different kind of interaction and configuration in 
> the current design.

If this use case doesn't fit the current design, IMO we should rethink
the current design.  We are just beginning to implement the user-level
features of project.el, so we should make sure adding other reasonable
use cases will be as easy as we can envision today.  _That_ is the
problem that bothers me the most: that we already have restrictions on
which use cases can and cannot be supported, although we barely
started.

> So ultimately, if you really want this kind of interaction, it would be 
> better to have a separate backend. It could also have a different author 
> than myself, thereby validating the idea that it is, indeed, something 
> that users want.

We are constantly losing focus in this discussion, at least from my
POV.  The main reason I started this is that I think using
default-directory for the decision which files/buffers belong to a
project is not the best idea.  Everything else I said, every example I
brought up, was to show why we should rethink that design decision,
and do so soon, not in some uncertain future.  This is the only issue
that really bothers me.  I didn't ask you to implement the "project
from existing files" feature, let alone change your priorities, I
didn't request any new commands or features, I just wanted to show how
this single design decision limits our future options.  This issue,
which is the only one important for me in this discussion, gets lost
time and again, because you take each my example and each my argument,
and start arguing about each one of them separately, thus drowning the
main issue in an ocean of related, but secondary aspects of the
problem.

Please, try re-reading or reconsidering all I said in that light, and
let's please return to talk about that one issue.  Assuming, that is,
that you are open to discussing that issue, and could be convinced to
change your mind; otherwise, let's agree to disagree and finish this.

TIA