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

From: Dmitry Gutov <[email-masked]>
Date: Wed, 1 Sep 2021 04:07:39 +0300

Hi!

On 31.08.2021 15:47, Philip Kaludercic wrote:
> 
> The following patch introduces a few functions for aggregate project
> maintenance:
> 
> - 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?

Another issue, is that it's not going to find nested projects (and 
project.el does support those).

Suppose we do add it, how about the name 
'project-remember-projects-under'? By analogy with 
'project-remember-project'.

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

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.

> - project-remove-projects-under
>    Remove all projects in a directory (inverse of
>    project-find-projects-under).

Similar question about popularity, but this one won't have a problem 
with semantics, at least (recursive-vs-non-recursive).

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