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

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philip Kaludercic <philipk <at> posteo.net>, 50297 <at> debbugs.gnu.org
Subject: Re: bug#50297: 28.0.50; Aggregate project functions for project.el
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?

Previous Next

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