[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: Eli Zaretskii
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Sun, 21 Jun 2020 18:08:04 +0300

> Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 21 Jun 2020 02:11:18 +0300
> 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

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

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.

> 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.  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.

> 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.

>         And project-switch-to-buffer should work with all kinds of projects.
>     Yes.  And one such kind is an ad-hoc collection of files and buffers,
>     where only the user knows which ones he/she is interested in and which
>     ones he/she isn't.  Every IDE I saw supports something like that, so
>     we should do that as well, IMO.
> I'm curious about those "every IDE". I don't recall such a feature in ones I 
> tried. Perhaps I just didn't use it, of course. 

Few examples below:


  Visual Studio:
  Look under "Create a project from existing code files", "Add files
  to a solution", "Create empty solutions"



  TI's Code Composer:

reply via email to

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