bug#63896: [PATCH] Support annotating and sorting the project list during completion

[Dmitry Gutov <dmitry@gutov.dev>]

Hi Spencer,

Sorry for replying late on this one. It looks like an interesting 
feature, going a bit further in the IDE department ("denser" UI).

I've tried the patch a little, here are some notes.

On 05/06/2023 00:20, Spencer Baugh wrote:
> Tags: patch
> 
> 
> This patch adds an annotation-function and display-sort-function to the
> completion-table used for project-prompt-project-dir and
> project-prompt-project-name, as well as a user customization variable to
> customize the behavior of the annotation and sorting functions.
> The idea is that projects are annotated with useful information for
> deciding which one you want to switch to, and sorted based on how likely
> you are to want to switch to or work on them.  For example, a user might
> want to know how many buffers they have open in each project, to help
> tell them apart at a glance.  Furthermore, a user might be more likely
> to switch to projects they've already been working on in this Emacs
> instance, so they might want projects with more buffers open to be
> sorted before projects with no buffers.

Or they might still like the MRU order, or some combination of that 
together with the number of open issues or compilation errors.

> All this is customized by the variable project-annotations which is a
> list of functions used to generate the annotations and sorting metadata.
> The user can add their own functions to add new annotations and sorting
> behavior.  See its docstring for more details.

What do you think about splitting it into two vars?

One for annotations (just text) and another for "sorters" (or 
something). Unless the performance difference is noticeable, decoupling 
the two will lead to better customizability: the fact that I want to see 
the numbers of errors doesn't necessarily mean I want them to be used 
for sorting. Or vice versa: I could move that number closer to the end 
in display, but prefer to have it weigh more prominently when sorting.

> I added three annotation functions as a starting point, which when added
> to project-annotations will annotate with the number of buffers, the
> modification time of the root directory, and compilation results.

Regarding the mtime one, we could also look at mtime of .git or .hg 
subdirectory when present, and take the max.

About the "compilation" one -- and this is nothing urgent -- I launch my 
compilation submode buffers using rspec-mode, not through 
project-compile. Might be useful to have that supported ootb without 
having to tweak the corresponding function. Just a search for 
compiletion-mode derived buffers belonging to the given project could work.

> In this patch I have turned all three of these annotations on by
> default, by putting all three in project-annotations, but probably when
> this is actually pushed we want project-annotations to be empty by
> default.  (Maybe?)

Probably. Up for later discussion, I guess.

We could also run an experiment.

> In my own packages, building on this, I hope to add annotation functions
> like "number of bugs assigned to you in this project" and "number of
> lines of incoming code to review in this project", so that
> project-switch-project is a nice way to pick what to work on next.

Very cool. Nothing that we could include ootb, but if you have a system 
which fetches the info over time and caches locally, that would be a 
great addition.

> This patch is still a bit rough around the edges, but I'm posting it now
> to get feedback.

Two problems I encountered when testing:

- It tries to connect to remote directories which have no currenct 
connection. This line:

+                    (cons (car dir) (project--find-in-directory (car 
dir))))

I fixed it by adding

   (when (or (not (file-remote-p (car dir)))
                  (file-remote-p (car dir) nil t))
     ...

but there might be a more efficient solution. We could drop remote 
projects from this altogether, but OTOH some users could work 
exclusively over Tramp (e.g. in local Docker VMs). Something to think about.

- The (return ...) call needed the cl- prefix. It doesn't compile 
otherwise (and breaks in 'emacs -Q').