[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50297: 28.0.50; Aggregate project functions for project.el
From: |
Philip Kaludercic |
Subject: |
bug#50297: 28.0.50; Aggregate project functions for project.el |
Date: |
Thu, 02 Sep 2021 13:30:15 +0000 |
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
- bug#50297: 28.0.50; Aggregate project functions for project.el,
Philip Kaludercic <=