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

[Dmitry Gutov]

(Continuing from the previous email.)

On 21.06.2020 18:08, Eli Zaretskii wrote:
> > I don't want to dismiss the critique outright. Believe it or not, I really do 
> > want you, personally, to be happier and more productive as a result of things I 
> > do here. I spent several hours today just thinking about this discussion. But 
> > our workflows are different, and expectations are different as well, and it 
> > seems that your requests tend to conflict with some design choices I have 
> > originally made.
> >
> >
> > One of them was to make the VC project a hands-off backend, one that immediately 
> > "just works" (or tries to), with a few possibilities for customization through 
> > local variables.
>
> This must be supported, of course.  And the backend which treats an
> entire directory with its subdirectories as a project must also be
> supported.

At this point I'm somewhat inclined to merge these two into one.

> I'm not arguing for dropping any of these two.  I'm arguing for adding
> yet another possibility, whereby the files belonging to a project are
> selected by the user, whether by marking in a Dired-like directory
> display, or by explicitly naming each file to be added, or by
> drag-n-drop.

Acknowledged.

It's a pretty alien UI paradigm for me (micromanaging project 
configuration like that). Similarly, I never got into using tags tables 
because that requires to both generate a file, re-generate it manually, 
and visit it manually as well. I have seen similar sentiments expressed 
by other users. (Having said that, I hope to return to adding a feature 
that auto-generates and regenerates tags tables for the current project 
using etags, one of these days.)

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.

OTOH, along the lines of Juri's opinion, perhaps your requirements could 
be satisfied by making use of whitelisting entries in VC project config. 
But if your projects indeed span multiple directories, the config 
couldn't reside in some particular root, then that calls for a separate 
backend.

> Based on the discussion of non file-visiting buffers related to a
> project, I think there should also be a command that would allow the
> user to include/exclude such buffers from the project, because it
> doesn't make sense to me to decide up front that any *shell* or *grep*
> or whatever buffers are automatically considered to be part of the
> project based on something as ephemeral as their default-directory.

As I explained, with project-vc you don't "decide" anything like that up 
front, you just internalize the idea that any buffer with 
default-directory inside the project's root more or less "belongs" to 
that "project" (the meanings of both terms are apparently different from 
how you use that words). So, if you need to switch to said buffer, you 
make sure to use the appropriate command (either project-switch-buffer, 
or switch-buffer, or project-switch-project).

> > You seem to think (and this is only my guess, of course) that a project is a 
> > unit of work. And that whatever files, or activities, are pertinent to your 
> > current goal, are a part of that project. Hence, if you do a search anywhere, 
> > in any directory, but in pursuit of that goal, the search results are certainly 
> > a part of the current project. It is certainly a valid viewpoint, but one that 
> > I have never considered before.
>
> I think it needs to be considered because it's a valid use case and
> happens in practice.  It would be useful to support it OOTB.

I'd like to make this clear: it's not a "use case", it's a point of 
view. If one considers a project to roughly be a "directory with files 
in it", and their work spans several such directories, they will think 
that the work spans several projects, and that's it.

> Even if
> all the files belonging to a project are in the same directory, the
> MO where _all_ (or a vast majority) of the files in a directory belong
> to the project is a serious limitation, and we shouldn't impose it on
> our users.  Granted, one can produce a large enough exclude/ignore
> list to leave only a handful of files, but if just 5% or 10% of files
> in a directory should be part of a project, excluding the other 90% or
> 95% is a nuisance and an unnatural thing to do.

This sounds like a use case for whitelist entries.

> > So I'm not sure where to go from here. If the latter viewpoint has more 
> > supporters, perhaps an new, alternative backend is the way to go. This would be 
> > a test of the API, how well it adapts to different goals.
>
> 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.

Having interactive commands affect project-vc's configuration is a murky 
idea, having two different ways to configure it. And it would have to 
add some new variables as well, that affect its behavior. Or some other 
configuration storage.

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.