Re: UI inconveniences with M-.

[Stefan Monnier <monnier@iro.umontreal.ca>]

[ Moving this to emacs-devel.  ]

> Maybe the solution is to define the ability for a backend to return groups,
> probably nested ones.

I don't see much need for nesting.  I think the issue is mostly one of
sorting in *xref* (or in the cycling, if we were to use a hypothetical
other UI that provides functionality like the old etags.el).

So, let's focus on this.
My suggestion would be either:
- make xref-find-function return not just a list of locations, but also
  an indication whether they're pre-sorted or not.
- make xref-find-function return not a list of locations, but a list of
  lists of locations (i.e. every location inside a sub-list is
  considered to have the same "level/quality/likelihood", but the lists
  are sorted by their "level/quality/likelihood").
- let the backend provide its own sorting function to override the
  current "group by file" sorting.

Basically, I think the focus should be on making sure that we can
re-implement the old behavior on top of the new API when using the
xref/etags backend.

Another thing that we should consider is how to let the user choose
which backend to use.  Currently we only have xref-etags-mode, but
I think it would make sense to make it possible for the user to
dynamically choose among the potentially many more backends (e.g. we
could add an xref/grep backend, and there will hopefulyl be more using
things like id-utils, gtags, ...) and maybe also to use several backends
at the same time (merging the results).  I don't have any suggestions
for what this could/should look like, OTOH.  But maybe one way to do
that would be to let each backend expose via the API a set of knobs
(one of which would be an "enable/disable" knob), and then provide an
xref command that can manage these knobs conveniently.


        Stefan