[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Mon, 29 Jun 2020 01:14:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

(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

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]