bug#50297: 28.0.50; Aggregate project functions for project.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 02.09.2021 16:30, Philip Kaludercic wrote:

>>> - project-find-projects-under
>>>     Select a directory with projects to index all at once.
>>
>> I wonder how popular this is going to be. Do you have a flat directory
>> with projects which you only want scanned one time?
> 
> I clone most code into a directory, and I have seen others do so
> too. That being said, it might just be something unusual in the big
> picture.

I think it's usual enough, but since we try to enable all kinds of 
practices, we should try to handle as many as feasible.

I'm mostly worried about the semantics here: we say we scan all the 
projects in said directory, but we can miss some (or many). That can be 
fixed with an edit to the docstring, of course (e.g. "directly below").

>> Another issue, is that it's not going to find nested projects (and
>> project.el does support those).
> 
> My first implementation of the command tried to so something like that,
> but it was rather slow (even if I currently only have 20 projects
> checked out), and indexed a lot of projects that I wasn't interested
> in. Maybe I can look into how it can be accelerated or only search for
> nested projects when a prefix argument is supplied/not supplied.

It might be fine as it is, behavior-wise. It never occurred to me to ask 
or search for such functionality, though, so me might want to wait for 
others to chime in (who will want to use this). I'm usually fine with 
'C-x C-f' when visiting a project the first time.

>> Suppose we do add it, how about the name
>> 'project-remember-projects-under'? By analogy with
>> 'project-remember-project'.
> 
> I like it.
> 
>> Adding a new arg for the latter is fine by me either way.
>>
>>> - project-remove-zombie-projects
>>>     Check if all known projects still exist and remove those
>>>     that don't anymore
>>
>> Perhaps we should rename 'project-remove-known-project' to
>> 'project-forget-known-project'? That would make for a nice symmetry.
>>
>> Then this function could be called 'project-forget-zombie-projects'.
> 
> This also make sense. Initially I wanted to name the command that way,
> but then decided to go with "remove" to keep the naming consistent.

We might encounter some resistance (the command has been with us for 
half a year), but let's try it, at least. We can also ask Theodor 
whether he has already used the current name, 
project-remove-known-project, in some Lisp code.

>> I'm thinking about this about the slight connotation of 'remove' which
>> can mean removing from disk.
>>
>> Another approach would be to call this or similar code automatically
>> before saving the list (and cap the number of remembered projects),
>> but that comes with its own tradeoffs.
> 
> I can try it out, but I fear it might lead to annoying pauses,
> especially when a project was indexed via TRAMP.

We could skip remote projects entirely in that function (leaving it to 
the user to 'forget' them manually), or only do it for already connected 
hosts. The latter could still take some time, though.

Do you expect project-forget-zombie-projects to be useful to remote 
hosts as well? Do you also have directories on remote hosts that contain 
many projects?

>>> Especially the last two are useful to maintain a clean project list
>>> without having to manually remove every project one by one.
>>
>> What if the goal was to maintain a clean project list but minimize the
>> manual management of it by the user?
>>
>> Can you imagine a solution for that? What would be the downsides,
>> compared to the present proposal?
> 
> I can imagine zombie projects being cleaned up automatically, but
> the motivation to write project-remove-projects-under was to remove
> projects that were falsely indexed.

Could you elaborate? Falsely meaning projects you simply don't want to 
return to? A whole directory of them?

> An entirely different approach might be to implement a tabulated list
> major mode to manage projects, comparable to package-list.

I don't object to supporting this approach, built-in or in a third-party 
package, as long as we're reasonably sure there is no low-touch, 
automatic solution we can use with a similar success for the problem in 
question.

If there's none, or if we found such, and then figured that some manual 
management on top of it can still be useful, that is fine.