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

[Philip Kaludercic <philipk@posteo.net>]

Dmitry Gutov <dgutov@yandex.ru> writes:

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

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.

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

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

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

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

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.

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

-- 
	Philip Kaludercic