@U02Q6L92FEJ Did you create a bb.edn?

yes I did

maybe restart clojure-lsp? then it should detect the root

I don't know if neovim lets you select the root interactively, @U7ERLH6JX?

yeah clojure-lsp only looks for deps.edn, .git and project.clj

or maybe its a nvim lsp specific conf, checking

yeah you can change the root_dir here: https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md#clojure_lsp add bb.edn

I see a number of things here mentioning bb.edn: https://github.com/search?q=repo%3Aclojure-lsp%2Fclojure-lsp%20bb.edn&type=code @UKFSJSM38 could you confirm that clojure-lsp is not selecting the project root based on that?

not sure if its a thing in clojure-lsp, but can definitely change it at the nvim level

i'll see if i can add it as a PR to nvim

I think this is something that can be done on the clojure-lsp side

but maybe ericdallo can comment on that

snippet to config:

local lspconfig = require("lspconfig")

lspconfig.clojure_lsp.setup({
  root_dir = lspconfig.util.root_pattern("project.clj", "deps.edn", "build.boot", "shadow-cljs.edn", ".git", "bb.edn")
})

the project-root dir is totally specified by the client and not by the server during the initialize request, so this is something to improve on nvim side, lsp-mode for example use .git folders via projeticle to guess the correct project-root still asking user to confirm

ah I see

isn't it weird that the server can't give any hints about it, since the server "knows stuff" about the language?

the rationale is that the editor opens the folders so it's easier for them to know the root, there are LSP servers that don't have deps files so it'd be even harder for them to know the root

the client could say to the server: I opened this folder, what is a likely root candidate?

but I guess this isn't part of the language protocol

a weird omission

yeah, https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initializeParams anything about following strictly what client sends so we could "ignore" or use as suggestion to use our own root, but to be honest, that should add a extra layer of complexity as most servers rely on that info sent from client, so users are kind of use to have those configs in client side, but I agree the spec could support something better for that

https://github.com/neovim/nvim-lspconfig/pull/2515

@U02Q6L92FEJ if you update your nvim-lspconfig, bb projects should now work without any extra conf! 😄

@U7ERLH6JX the changes was pushed to master but It doesn't seem to be new release yet

Yeah I run the master one pretty much. No difference in stability and get all the good stuff! 😄

@U7ERLH6JX it's working! one less line in my config. Thank you!

when you say documentation you mean only clojuredocs or everything like arity and docstring?

also I see lots of configs overrides that may not be a good idea for global config, like • :source-paths which will make clojure-lsp relies only that for all projects and not discover the source-paths from classpath automatically • lots of default configs that are already the default in clojure-lsp like cache-path, text-document-sync-kind , dependency-scheme and others, if we improve the default in clojure-lsp someday, you may need to adjust manually each one of them Besides that, I don't see anything that could affect hover doc feature

For example, with my config I see docstrings for my own code defined in the project, but nothing for functions in clojure.core or libraries that have been included, e.g. mulog. I've found some keys and values that have changed (although have not found the issue). I'll comment out any default key/values that I am not changing I am not overriding :source-paths, but do override :source-aliases as I typically use those aliases in all projects

I did look at this issue a while back in https://clojurians.slack.com/archives/CPABC1H61/p1671736916152609 but didnt get anywhere

that sounds like wrong source-paths classpath configs indeed

the :source-paths key makes no difference if its included or not. docs are showing either way. This is not a surprise to me as the key has the same value as the default example

could you share the output of lsp-clojure-server-info ?

Also, I'm curious why your emacs is not processing the markdown from the docs

I'm currently using the example https://github.com/clojure-lsp/clojure-lsp/blob/master/docs/all-available-settings.edn config and running a diff against my own config, so currently the docs are working. I'll swap back and generate the log

the server info will tell what source-paths and classpath clojure-lsp is using to provide most features, that helps understand if a config wrong or missing

I think the offending key/value was :dependency-scheme :zipper_mouth_face: which should now use a "zipfile" value

The lsp-clojure-server-info output with this key with the incorrect value is at https://gist.github.com/practicalli-john/37b71e84478162aea7327590628a8933 if there is value looking at it.

It seems to be broken again after swapping files, so that does not seem to be the full story. I'll go back to rebuilding the config from scratch

Is the following a correct value for the jdk sources I have already installed on my local operating system

:java 
{:jdk-source-uri       "file:///usr/lib/jvm/openjdk-17/lib/src.zip" ;;
 :home-path            nil 
 :download-jdk-source? false
 :decompile-jar-as-project? true}

:java 
{:jdk-source-uri       nil 
 :home-path            "file:///usr/lib/jvm/openjdk-17/lib/src.zip"
 :download-jdk-source? false
 :decompile-jar-as-project? true}

You can use home-path when you want to point to a local jdk installation folder, but most of the time, the default is enough, using only jdk-source-uri to download and cache

Why you are overriding the java path? What from the default doesn't work for you?

You can override single settings as well, you don't necessarily need to override the whole map if there is any config you want to change

Thanks. I already have Java 17 sources installed for several uses, I would prefer not to also have to Java 19 sources installed (even if it is a 'reduced' src jar).

I have the config working properly and have commented all the key/value pairs that havent changed from the defaults, to add more resilience. Thank you