Re: xref "find references" and grouping

[Dmitry Gutov]

On 05/02/2015 05:14 PM, Helmut Eller wrote:

> Maybe the current group label could be generalized to a path in a tree
> e.g. (<file> <class> <method>) where each element of such a tree path is
> simply a string and the UI can display it either as a flat list or some
> of kind tree widget.

In this format, we lose the ordering, though. Then we'll have sorting 
functions, which would need to be returned with the data, and we'll need 
to decide whether there's one function, or several (per level).

Or we could tackle this in OO fashion.

The different actions in xref-find-function will be required to return 
"renderable" elements (better name pending), in a backend-defined order, 
and there will be no subsequent sorting (basically, like now).

Each of those will implement a set of generic methods:

- Render itself in the xref buffer.
- Return the xref location element at point.
- Move point to the previous or next location element.

Later, some extra stuff, if we reach the "rename" feature, like:

- Return all locations inside.
- Mark or unmark all locations inside.

(Marked location elements would render themselves differently).

The downsides, as I see them:

- Less transparent data structures than a flat list.
- Some overhead on virtual dispatch (but hopefully it'll be negligible).
- Backends having a lot more say in how the buffer is displayed, and 
thus having more opportunities to break the rendering, use their own 
extra-special faces, and reinvent the interface (for better or worse).

The last point might also yield benefits: the generally agreed upon UI 
improvements could then be pushed into the default rendering logic.

> Not really.  For a time we grouped compiler error/warning/notes with a
> kind of tree widget; the idea was to make it easier to skip over notes
> and warnings and see error more quickly, but in practice much time was
> spend on opening and closing those subtrees.  I don't know if a tree
> widget is a win.  In Emacs such things always seem to require a lot of
> extra screen space compared to the GUI widgets in other IDEs.

Please note that folding (and extra indentation for sub-elements) is not 
a necessary element of what I'm describing. We can just use different 
faces for group headings, and otherwise render everything flat (if 
anyone disagrees, it's easy to make customizable).

Most of the time I dislike code folding, and the idea to conflate 
expanding of the matches with marking (for renaming) in semantic-symref 
strikes me as unfortunate. It still looks nice, though.