Clojurians Log v2

actually it's done in clojure-lsp so no client extra work is needed, completing inside the string or the map should work

https://clojure-lsp.io/features/#library-names-and-version-completion

It works for me in Calva for deps.edn but it has quirks. For example, add io.github.clojure/tools.build to your deps.edn and it suggests all the git dep versions but not the Maven (Clojars) versions. It suggests coords for the lib, but if you start typing the coords, you don't get auto-suggestions (which is where I would have expected it to happen).

Feel free to open a issue on how to improve it, that code was tricky to do, but it should be fixable

It is quite quirky, yes. 😃

I guess my question would be: how exactly should it be expected to work? If I type io.github.clojure/tools.build {: I get the :git/tag auto-suggests. If I continue to type mvn/version " I do not get Clojars versions. I don't think I've ever seen it suggest versions inside the string, i.e., when I have this: io.github.clojure/tools.build {:mvn/version "|"} (where | is the cursor). Should I see completions there?

yeah that's the tricky thing, how we expect to behave. But yes, inside the string was supposed to work

Ah, I see it working with @seancorfield’s io.github.clojure/tools.build example. I tried completing clojure.core.async and it came up with a bunch of libraries, and after I typed in clojure.core.async, it gave all sorts of things (symbols?) for the version. I figured it wasn't working...

we do have https://github.com/clojure-lsp/clojure-lsp/blob/b3eec66d1027875ee1e5acc145ff2c368047a222/lib/src/clojure_lsp/feature/completion_lib.clj#L34-L38 for inside a string, but maybe there is some corner case

Sounds like something I could look into 🙂

It seems like this is my bad. I didn't know what the name of the library was and guessed clojure.core.async. It turns out that it's org.clojure/core.async. With that, it completes the library and the versions.

I wonder if there's some way to map from the library name that some newbie types in to the actual name?

I believe one thing we could do as a extra new feature is: a info diagnostic when the the lib is not found in any of the sources we search, but I feel like it can cause false positives in some private libs cases so not sure it's a good idea

dunno it's worth it to map those names too, can't think in many more cases

Yeah, I'll chalk this up to "bad user on device"

Thanks for the help!

> a info diagnostic when the the lib is not found in any of the sources we search, but I feel like it can cause false positives in some private libs cases In a Polylith repo, all the bases and components are pulled in as :local/root "libraries" -- that would be about 200 false positives for our setup at work so... I wouldn't be very happy about that 🙂

Part of the problem -- in general here -- is that the group/artifact ID of the library bears no connection to the namespaces that are inside it. clojure.core.async is a namespace. org.clojure/core.async is a group/artifact ID. LSP could special case some nses to lib names (basically clojure.X.Y => org.clojure/X.Y is relatively safe) but it could not do it in general.

> In a Polylith repo, all the bases and components are pulled in as :local/root "libraries" -- that would be about 200 false positives for our setup at work so... I wouldn't be very happy about that 🙂 Of course we could ignore for local/root, but yeah, for private libs and maybe other corner cases it could be a problem

hum, I wonder if we could use the same data from lsp-clojure-show-project-tree which we have lib names

But, given foo/bar as a libname, before the coords are entered, you can't tell if that's Maven, Clojars, git deps, or local...?

I don't think you can, you can search in all those, but not sure you can know for sure from where it comes

And then you have libraries like https://github.com/dm3/clojure.java-time where the group and artifact are both clojure.java-time which looks like a ns and you'd almost think org.clojure/java-time except it's really clojure.java-time/clojure.java-time (which, hey, blame the lib creator for a bad name there maybe?) and the ns is really java-time.api. I can't imagine any useful diagnostic here that wouldn't trigger false positives in a reasonable number of cases.

yeah me too

Ah, I didn’t know it wasn’t. Should be easy to fix. Please file an issue.

Issue filed https://github.com/BetterThanTomorrow/calva/issues/2986.