On Sat, Feb 15, 2025 at 5:09 PM Eshel Yaron <me@eshelyaron.com> wrote:

> Ship Mints <shipmints@gmail.com> writes:
>
> > Thank you for your thoughtful feedback.
> >
> > A couple of things stand out. First, calling completing-read directly
> means we can reuse the project-file
> > completion category (and if you use something like marginalia, you get
> nice metadata in your completion list),
>
> In my suggested approach we get the "file" completion category, which
> AFAICT marginalia picks up just as well and provides the same kind of
> completion annotations.
>
> > and which also now can inhibit sorting the completion candidate list,
> which I find can be annoying for this kind of
> > use case.
>
> Sorry, I'm not sure I understand the problem.
>
> FWIW there are several ways to control sorting besides specifying
> display-sort-function in the completion metadata, like completions-sort,
> completion-category-overrides and completion-extra-properties.
>

Hewing to the style of the project.el code base, considered choices like a
dedicated project-file category, and reusing/improving its own code seem
like good things to me. I'm not one of its maintainers, so I try to keep it
easy for those who are.


> > Second, since this is forget "under" directories, prompting with the
> common prefixes that allow one to forget
> > under the whole shebang makes more sense to me.
>
> You could still select a common ancestor directory (prefix) to forget
> all projects under it, if that's what you mean.
>
> > Perhaps your ancestor list generator can be more efficient than the
> > common-prefix code that I quickly wrote, and it would be helpful for
> > it to show all common prefixes, don't you agree?
>
> I don't see a lot of benefit in the flat list of all possible choices in
> this case, but no strong objection either, just a personal preference.
>

Not sure the common-prefix list is "flatter" than any other kind of list,
but it is convenient when one wants to forget projects on a remote host en
masse, or in the root of a directory tree that has script-kiddie git repos
everywhere (one day, they'll all learn that monorepos are the way) and I
want to forget everything I've seen (for more than one reason!).