Re: Bad moves with xref-find-definitions

[Dmitry Gutov]

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

> Not ideal but at least it's context free. And you don't need it that
> often from other places anyways.

I'd rather keep it as C-h f/v/o/m, and add snappier binding(s) for 
context-dependent command(s).

>   > Personally, I expect "serious" backends to either replace the need for etags
>   > entirely, or delegate to them and collect the results internally.
>
> It's not really possible. Sometimes you just need to open related
> project without "sourcing" it or an old version of the current project
> to keep it as a reference. No "serious" backend can accommodate that.

Why not `M-x projectile-switch-project', or something similar?

> Besides etags it might be potentially handy to have multiple backends
> within a mode. In clojure for example you can have one backend for pure
> clojure code and another for java code. If xref is able to merge
> backends and provide a nice UI to manage those backends then CIDER would
> not need to bother with merging or managing those.

I fail to see the benefits of keeping Clojure and Java identifiers 
separate. The commands easily choose one or the other based on the 
context, and if you're typing the identifier manually, the Java ones 
look distinctly different.

Also, while CIDER knows that Java and Clojure identifiers have no 
duplicates between them (and can simply concatenate the lists, or 
something to that effect), the generic code cannot know that.

> As this and other threads suggest managing backends is a non-trivial
> task. If you leave this task to major modes everyone will cook his own
> soup resulting in a variety of different interfaces.

If I have to guess, the built-in major modes will use comparatively 
simpler approaches (like python-mode's delegation to the REPL process to 
fetch completions), but third-party minor modes can provide smarter 
integration.

I definitely don't want to see here micromanagement a la Icicles in the 
default interface.