Re: Bad moves with xref-find-definitions

[Dmitry Gutov <dgutov@yandex.ru>]

On 04/26/2015 07:01 PM, Vitalie Spinu wrote:

> Aha! I see. Would be nice to be able to flush those into some familiar
> interface - IDO, HELM or at least grep-like buffers (compilation
> buffers) so that one can use M-g n, M-g p without visiting the buffer.

If you don't like xref--xref-buffer-mode, you're welcome to assign a 
different xref-show-xrefs-function.

>   > Not if you want to avoid duplicates. ...
>
>   > So you can simply call `delete-dups' on ...
>            ^^^ cannot?

Right, sorry.

> What's the exact problem except abandoning lazynes? Naively I think
> about it like this. Gather all candidates. Delete-dups. Then take
> backends in turn and see which one contain the reference. If unique, use
> that backend, else use *xref* buffer.

When there are more than one, we show all matches in the xref buffer. I 
believe showing duplicates in there would be confusing.

Or similarly, if one adapts a tags-loop-continue-like interface for 
this, this command would visit certain locations multiple times.

> I personally never had problems with too many candidates, so "being
> lazy" is completely useless feature to me. I am also not convinced you
> are gaining much speed here. Each backend has to operate with its own
> list of candidates anyways.

Admittedly, the place where the speed improvement is the most glaring is 
the xref-find-apropos command.

Before laziness, it was much slower than `M-x apropos'.

The other problem is what to do with all the files we have to open in 
the process. Do we leave the buffers open? Or do we kill them after 
generating the list, to open again when the user navigates to a 
reference? Or if they abort and repeat the same command with the same 
(or a similar) argument.