[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bad moves with xref-find-definitions

From: Vitalie Spinu
Subject: Re: Bad moves with xref-find-definitions
Date: Sun, 26 Apr 2015 22:56:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

 >>> Dmitry Gutov on Sun, 26 Apr 2015 20:51:02 +0300 wrote:
 >> 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?

Because you need an interactive repl running to have dynamic completion
for one, and for multiple language projects you don't have access to
C/Fortran etc definitions from the interactive session anyways. So at
least the etags integration should be done properly in the core.

 > I fail to see the benefits of keeping Clojure and Java identifiers
 > separate.

Generally you don't want to clutter completion or location tables with
java symbols from all the projects that you import. %99.99 of those are
useless. In most cases you need clojure and java symbols in current
project. Next level is all core and imported clojure symbols. Then all
java classes/methods.

There is an open issue in CIDER on interactive doc completion where this
was discussed [1]. Bozhidar can comment on this more, but the general
idea is that you want to offer completion candidates in some sort of
stages in order to avoid impairing the usability. I think the same
concern is valid for references (for the prompt case and apropos at


[1] https://github.com/clojure-emacs/cider/issues/1059#start-of-content

reply via email to

[Prev in Thread] Current Thread [Next in Thread]