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

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.
>> - project-remove-zombie-projects
>>    Check if all known projects still exist and remove those
>>    that don't anymore
>> - project-remove-projects-under
>>    Remove all projects in a directory (inverse of
>>    project-find-projects-under).
>> Especially the last two are useful to maintain a clean project list
>> without having to manually remove every project one by one.
>
> OK, so I have done the rename: we now have project-forget-project.
>
> While I'm not necessarily a fan of the tabulated list approach, the
> above list looks sensible. Let's just name them to fit the current
> scheme better:
>
>   project-remember-projects-under
>   project-forget-projects-under
>   project-forget-zombie-projects

It is also my impression that the tabulated list doesn't make too much
sense (for now).

> And whatever ambiguities about recursive search can be solved through
> better descriptions in docstrings.

Ok, I will update the patches and refine the documentation. My plan
would be to be non-recursive by default, and recurse if a prefix
argument is given.

> We could also add a hook like project-after-read-list-hook, which
> people would be able to use for cleanup, e.g. adding
> project-forget-zombie-projects to it. Not sure whether to add it there
> by default, though.

The question is does it make sense to not always forget zombies? This
depends on the real-world performance. If it is a noticeable burden (at
least on some systems), users might prefer adding the function to
kill-emacs-hook instead of a project-after-read-list-hook.

-- 
        Philip Kaludercic