I'm researching improving clojure-lsp startup making analysis async (like other LSPs like Dart), would love your feedback/input on https://github.com/clojure-lsp/clojure-lsp/issues/2041
A tenuously related 'performance' issue (quite minor). The serverInfo.version information reporting may be slower than Neovim caters for, via vim.lsp.health checkhealth. It seems not to provide a response in time (I guess it could be a parsing issue or due to install via mason).
Would the serverInfo.version call be the same as running clojure-lsp --version on the command line?
I'll raise an issue if it seems worth investigating.
Output from within Neovim checkhealth
==============================================================================
vim.lsp: require("vim.lsp.health").check()
- LSP log level : WARN
- Log path: /home/practicalli/.local/state/nvim-astro5/lsp.log
- Log size: 13 KB
vim.lsp: Active Clients ~
- clojure_lsp (id: 1)
- Version: ? (no serverInfo.version response)
- Root directory: ~/projects/practicalli/clojure-cli-config
- Command: { "/home/practicalli/.local/share/nvim-astro5/mason/bin/clojure-lsp" }
- Settings: vim.empty_dict()
- Attached buffers: 12
vim.lsp: Enabled Configurations ~
vim.lsp: File Watcher ~
- File watch backend: Custom (@/tmp/.mount_nvimJEgpiI/usr/share/nvim/runtime/lua/vim/_watch.lua)
vim.lsp: Position Encodings ~
- No buffers contain mixed position encodingsServer info is pretty fast, probably a Edn parsing performance issue on vim side as it may return a medium size edn
Edn?
Server info returns info as Edn I believe
I'm surprised vim would parse EDN. Wouldn't JSON make more sense?
Not sure if they really parse, but that's how it works today, other editors like emacs and calva do that, so changing to json would need a flag or so
Good to know. The version was reporting okay last year and am sure they extended the timeouts, so a parsing issue sounds more likely. I'll find some time to dig around and see if I can find where in Neovim is dropping the info. Thank you.