Closed siduck closed 2 years ago
Hello! Hm. I will assume java
is installed on path. What does the LSP log say (~/.cache/nvim/lsp.log
)?
OS: Windows 11
Very similar issue on my end, it might provide more info @williamboman. In my case, clangd
for C is not loading for the same reason:
I have installed it, as you can see, and it used to work just a couple of days ago. Then I updated the plugin and it seems to have broken the "auto insertion of path to server" as is mentioned in the README.
In the pic of :LspInfo
, I used to see the path to the installed server in cmd
instead of clangd --background-index
, which is what lsp defaults to if no inputs are provided.
In my lsp-installer config, I needed to pass in some custom info for nvim-cmp and sumneko_lua, and as such I followed the Advanced config: Overriding default lsp options basically to the T.
EDIT: Just noticed that commit 095ab4e mentions needing to reinstall. lol, sorry for the ping. 😄
EDIT 2: If you are here now, and don't mind me asking, what does "it now provides an amended PATH" mean? And why is cmd
not used anymore? I mean, it is a good thing as it opens up cmd for other flags that one might want to send, but what does PATH mean?
Hello @Pranav-Badrinathan! Yeah in the interest of getting rid of some bad historical decisions, unfortunately that commit broke ltex and clangd installations. I'm working on #340 to help mitigate this, so that pulling a new version of the plugin should have minimal (if any) effects on your already installed servers (any changes would only be applied once you update the servers themselves).
EDIT 2: If you are here now, and don't mind me asking, what does "it now provides an amended PATH" mean? And why is
cmd
not used anymore? I mean, it is a good thing as it opens up cmd for other flags that one might want to send, but what does PATH mean?
An amended PATH is a bit lazy phrasing from my part. But in essence; What allows a piece of software to identify where an executable is located on the system is the PATH variable. All server configurations in lspconfig assumes that the server executable exists somewhere in PATH. However, this plugin will not install server executables to any location that is in PATH (you can of course manually add these locations to your PATH, but that's very tedious).
So, how this plugin worked prior to that commit was to provide a cmd
to lspconfig which contained the absolute path to the locally installed server executable file (for example ~/.local/share/nvim/lsp_servers/tsserver/node_modules/.bin/tsserver
). Because the cmd
was overridden in its entirety, we'd also have to make sure to provide any necessary extra arguments (like --stdio --hostPID=x
). For these we'd essentially just mirror what was defined lspconfig. This caused duplication across the two plugins but also a drift as changes are made.
neovim uses libuv for a lot of things under the hood. For example, it uses uv_spawn
(vim.loop.spawn
) to start language servers. When calling uv_spawn
with a command, for example vim.loop.spawn("tsserver")
, it will try to locate the actual location of the tsserver
executable by using the PATH environment variable. Due to some recent changes made in core neovim, we can now make use of this in this plugin to hopefully help mitigate some of the problems mentioned above! In essence, we tell lspconfig to start each server with a custom PATH environment variable that will allow uv_spawn to find it.
- cmd: ~/.local/share/nvim/lsp_servers/tsserver/node_modules/.bin/tsserver --stdio
+ cmd: tsserver --stdio <-- now provided by lspconfig
- PATH: /usr/bin
+ PATH: ~/.local/share/nvim/lsp_servers/tsserver/node_modules/.bin:/usr/bin
So, how this plugin worked prior to that commit was to provide a
cmd
tolspconfig
which contained the absolute path to the locally installed server executable file. Because thecmd
was overridden in its entirety...
Glad this is not the case anymore.😌 I personally tried passing flags via cmd
and found out that doing so breaks the system.
In essence, we tell lspconfig to start each server with a custom PATH environment variable that will allow uv_spawn to find it.
A more elegant solution that does not really require any user interaction, solves code duplication between plugins, and makes cmd
accessible to the user. Nice.
Thanks for your reply!
~/.cache/nvim/lsp.log
I still get the same error :c
What does the following produce?
$ java -version
$ find ~/.local/share/nvim/lsp_servers/jdtls -iname '*equinox*'
What does the following produce?
$ java -version $ find ~/.local/share/nvim/lsp_servers/jdtls -iname '*equinox*'
i dont work with java, someone using nvchad had this issue so i tested it myself. i thought only java lsp was required but java is needed too?
Yes a JRE is needed as it runs .jar files!
I pushed 60e411d146e7d6892732195cd3f9c0ab7bb76383 which hopefully makes this easier to catch earlier.
@williamboman i no longer get the path issue but the lsp starts with this
works!
thanks a lot @williamboman
As for the progress messages: the way jdtls has implemented progress reporting isn't per the LSP spec, so it just prints the messages by default.
I've got this in my personal config, which maps their custom progress reporting to the $/progress
handler (which I've hooked up to lualine, see below). I'll try to see if there's interest to include this upstream in lspconfig.
@williamboman one more thing, the icons used in the lspinstaller's gif in the readme look nice but the default ones look bad
could you make these icons default?
Yeah the default ones are pretty bad. The thing is that the icons I use in the recording is part of the nerd font collection. If your font is not compatible with it, it will either render some other character or nothing at all. It'll have to be an icon within the standard unicode range. Happy to take suggestions for such candidates
Hi @williamboman, what font are you using? It look very good!
Hi @williamboman, what font are you using? It look very good!
jetbrainsmono probably
Correct! JetBrains Mono (Nerdfont variant)
I installed the jdtls server but i get this path issue