GNU bug report logs - #50297
28.0.50; Aggregate project functions for project.el

Previous Next

Full log

Message #31 received at 50297 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 50297 <at> debbugs.gnu.org
Subject: Re: bug#50297: 28.0.50; Aggregate project functions for project.el
Date: Wed, 22 Sep 2021 07:15:00 +0000

Dmitry Gutov <dgutov <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.