[Top][All Lists]

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

Re: Bad moves with xref-find-definitions

From: Dmitry Gutov
Subject: Re: Bad moves with xref-find-definitions
Date: Tue, 28 Apr 2015 00:57:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0

On 04/26/2015 11:56 PM, Vitalie Spinu wrote:

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.

We're talking about using some new tags table, to jump to a file in a different project, right? How come it's important to have a running repl, then?

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.

Note that these levels are not split along the lines of Clojure/Java.

And while it seems like it could a sensible approach, I don't exactly see a solution in terms of new xref features.

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

But the currently suggested approach proposes to use one completion table for all stages.

reply via email to

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