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!).