Completion candidates for cider-find-var prompt

[expez]

The prompt currently only contains thing-at-point. It would be nice if it also contained all other vars that are reachable from the current ns.

[bbatsov]

Try tab completion for cider-find-var. I'd argue the current behavior is way better than the alternative, although that's not apparent to ido users.

[expez]

Can we get some optional ido-love up in here, then?

[bbatsov]

Can we get some optional ido-love up in here, then?

Unlikely - what makes sense in a language without namespaces (like Elisp), doesn't make a lot of sense in Clojure. There used to ido-friendly completion - first you'd see all the namespaces, you'd select one and then you'd see a list of all the vars. I killed this however, because it was super annoying to do 2 levels of selection all the time. cider-doc was also a concern - it operates on both Clojure and Java constructs, so using a Clojure-specific completion there didn't make sense and mixing Clojure and Java in an ido-friendly manner was pretty hard.

If somebody comes with a really nice idea how to organize this - I'll be willing to reconsider it.

[expez]

Why didn't you just go with a list of fully qualified vars?

[bbatsov]

Why didn't you just go with a list of fully qualified vars?

Looked kind of ugly to me (plus I had some performance concerns for bigger projects and ido-flx).

[vspinu]

Unlikely - what makes sense in a language without namespaces (like Elisp), doesn't make a lot of sense in Clojure. T

It makes sense as long as the names are unique. Non-unique elements could be qualified with namespace, or better ask for the namespace after a non-unique candidate has been selected.

BTW, adding INITIAL-INPUT is pretty non-standard emacs. It's much better to have the default choice. Ido also recognizes default choice and shifts it in front automatically. The initial input is unnecessary in all cases.

To be frank, this abomination with cider-read-from-minibuffer leads to rather confusing code and behavior. Cannot CIDER just use completing-read instead of trying to outsmart standard emacs? I would really appreciate if Cider completion worked as everywhere else in emacs, with or without IDO.

[bbatsov]

It makes sense as long as the names are unique. Non-unique elements could be qualified with namespace, or better ask for the namespace after a non-unique candidate has been selected.

That'd be a terrible idea, as adding namespaces to your project will constantly change your completion candidates. We should probably have everything fully-qualified and we should also have ns aliases in mind and interned vars in mind.

BTW, adding INITIAL-INPUT is pretty non-standard emacs. It's much better to have the default choice. Ido also recognizes default choice and shifts it in front automatically. The initial input is unnecessary in all cases.

I'm not quite sure what you mean or what's the problem right now.

To be frank, this abomination with cider-read-from-minibuffer leads to rather confusing code and behavior. Cannot CIDER just use completing-read instead of trying to outsmart standard emacs? I would really appreciate if Cider completion worked as everywhere else in emacs, with or without IDO.

This is pretty much impossible to avoid for the commands dealing with both Clojure and Java code. We'd be crazy do dump all the java classes and methods in a list... completing-read is great for simple non-hierarchical data, but things get messy in situations like ours (unless we flatten everything). I don't think we're doing something super crazy, although admittedly it's not super pretty either.

As I said before - if someone develops something super cool I'd happily consider using it.

[bbatsov]

The current behaviour is not without benefits.

[turbopape]

Completely irrelevant but what is the font you are using in your last
screen capture @bbatsov?
Le 4 avr. 2015 12:04, "Bozhidar Batsov" notifications@github.com a écrit :

[image: screenshot 2015-04-04 13 57 32]
https://cloud.githubusercontent.com/assets/103882/6992391/7c14df00-dad3-11e4-946d-3613f5b9f57b.png

The current behaviour is not without benefits.

—
Reply to this email directly or view it on GitHub
#1059 (comment)
.

[expez]

Without INITIAL-INPUT but with a default selection:

With INITIAL-INPUT used as default selection:

I'm not quite sure what you mean or what's the problem right now.

The problem is that it's non-standard and that you now have to erase the content if you don't want the default suggestion before typing something else.

[vspinu]

That'd be a terrible idea, as adding namespaces to your project will constantly change your completion candidate

In what sense do they change? There are simply more completions added. That some of those might not be unique anymore is true., but this is why the second level prompt for the namespace should be there.

BTW, adding INITIAL-INPUT is pretty non-standard emacs. It's much better to have the default choice. Ido also recognizes default choice and shifts it in front automatically. The initial input is unnecessary in all cases.

I'm not quite sure what you mean or what's the problem right now.

The problem is that the thing-at-point is inserted at prompt (aka INITIAL-INPUT in completing-read terminology) and you have to delete it if you don't want it (most commonly for me). In emacs it's customary to have the default choice which could be accessed with RET, and leave the minibuffer input clean.

This is pretty much impossible to avoid for the commands dealing with both Clojure and Java code. We'd be crazy do dump all the java classes and methods in a list...

Even if java objects/methods are restricted to only those imported in the current namespace?

As I said before - if someone develops something super cool I'd happily consider using it.

How about merging current completion mechanism with standard completing-read. That is, offer most likely list of candidates which is a subset of all candidates (all clojure, imported java) and on M-TAB get the completion popup as it's done currently.

You can also grow the completions dynamically. That is, have an original set of completions, and as user typed 2 letters request all of the remaining completions that start with those 2 letters.

[vspinu]

Without INITIAL-INPUT but with a default selection:

@expez What is the completion engine in your first screenshot? Never seen this before. Feels like I am missing something big.

[bbatsov]

Seems it's ido-vertical.