completion for java-interop calls about clojure-complete HOT 4 OPEN

ninjudd: As far as java completion goes, I didn't consider tackling instance method completion because the instance type is unknown when you are typing the method. That's why ns-java-methods only returns static method names.

(Imported from another issue)

from clojure-complete.

trptcolin: For REPLy's needs, instance method completion for imported classes would be awesome. I've had it on my to-do list for awhile. Your ns-java-methods change seems right to me as well - it might already work after dropping that in.

(Imported from another issue)

from clojure-complete.

kotarak:As for the method completion: It could be limited to methods of import'd classes. That would be better than nothing and have a certain probability of matching.

(Imported from another issue)

from clojure-complete.

@ninjudd , @trptcolin , @kotarak : Indeed the fundamental problem is that the completions one would like to get are hard to get right, because there's not enough context. In my particular case of hacking Counterclockwise in Clojure, it's especially harder to work with the Eclipse API from Clojure code than from Java code where I'm accustomed to "discover API via code-completion as you go" - style.

So for this particular function, having only the prefix and the current namespace as context are far from ideal.

But I agree with Meikel and Colin that having, for a start, instance method completion for classes imported in the current namespace is better than nothing !

In the future, we may have to think about ways to gather more "context" for this style of completion : for example IDEs could try to be "smart" by "sneaking" the types of the input/output objects passed to functions during tests.

Another idea, stolen from Enclojure : give the context by having the prefix include the class imported name (or any class fully qualified name) : "String/toS" would then resolve to ".toString"

from clojure-complete.