I see the progress of lua_ls when loading my astronvim-config project. I havent noticed luacheck, but maybe that runs much faster...

Maybe it's not luacheck per se, but it takes some time for LSP (via null-ls?) to make the code available for LSP actions such as renaming or finding references. I wanted to see that progress so that I'm not stuck trying to gr to find references and instead ending up as if I'd just hit r. Right now I go by the syntax coloring that changes once LSP has done its job. Is there another way?

I havent written much lua myself, mostly copy paste. However, if I type vim. and press tab I do see completion. I havent tried references, not sure what references I would actually try and jump too in lua. Do you have an example of what you are trying to do?

SPC l I will show the lsp server info, including the log location. I assume running tail in a separate window would show some information (although not clear if this would be helpful), e.g.

/home/practicalli/.cache/astronvim/null-ls.log

Sorry I may have misdirected the question by saying luacheck which is just what I saw on the screen, but this is a Clojure project

So with gr I'm trying to pull up the places where, say, a certain fn is being used

Using AstroNvim and the Practicalli AstroNvim user config then gr on a function call seems to work with a Clojure project, both within the current file and across .clj files within the project classpath. Pressing gr with the curson on a function call opens a telescope dialog with the matching locations found in the project, including the current line it seems.

gr doesnt seem to work for function calls to functions defined in libraries added to the project...

I get the following error when trying to navigate to a function in a library (rather than the project source code). I havent processed this error as yet, so not sure what the issue is.

Error executing vim.schedule lua callback: ...t_nvimfV1UR1/usr/share/nvim/runtime/lua/vim/lsp/util.lua:1828: index out of range
stack traceback:
	[C]: in function '_str_byteindex_enc'
	...t_nvimfV1UR1/usr/share/nvim/runtime/lua/vim/lsp/util.lua:1828: in function 'locations_to_items'
	...nvim/lazy/telescope.nvim/lua/telescope/builtin/__lsp.lua:27: in function 'handler'
	....mount_nvimfV1UR1/usr/share/nvim/runtime/lua/vim/lsp.lua:1393: in function ''
	vim/_editor.lua: in function <vim/_editor.lua:0>

Yes, gr works fine for me in that sense (even for libs after I enabled zipPlugin). What I'm trying to get at is that there is a certain amount of time after I open the first clj file in a project during which it won't, nor will any LSP command - I'm assuming that LSP is doing its thing, building up ASTs and everything it needs to operate, and I wanted to know how that is progressing. Let me record a video to clarify myself.

Maybe LSP (clj-kondo) is indexing Java or some large data set. I disabled java as it gives way too many java methods on all the autocomple popups (which I find annoying given very limited use of java interop) In .config/clojure-lsp/config.edn, I set the :java key to nil

:java nil

I would not expect to see the "installing luacheck" each time. To me that suggests there is an issue trying to install the package, although why it is trying to install luacheck for a clojure project seems quite strange as well. There could also be an issue with the mason configuration. Does the mason status popup show any issues or outstanding packages, e.g. SPC p m

One brute force approach is to use the mason UI, SPC p m to uninstall the luacheck linter. Then see what happens when quiting neovim and starting neovim again. I did have a couple of linters that failed to update and I had to remove them using mason and then reinstall after a neovim restart.

Thank you, now I understand what the message is actually trying to say. It does show an error

✗ luacheck
      ▶ # [3/3] spawn: luarocks failed with exit code - and signal -. luarocks is not executable

Is luarocks installed ? It should be runable within a mac terminal ap

Nope. I might have missed that requirement.

Alright, I got a successful install of luacheck now

Does that also improve the startup time for the Clojure LSP UI in neovim, so actions and gr is more responsive?

Nope, didn't feel any difference

SPC p M should ensure that the clojure-lsp is running the latest stable version. setting :java nil in the Clojure LSP server configuration may be a useful optomisation (if you dont use a lot of java interop) I also suggest trying a smaller project (or newly created project) to see if its an issue with the Neovim / Clojure LSP setup or only specific (larger) projects. If its larger projects, then there probably isnt much to be done (unless there is not enough memory available on your computer, which is probably unlikely). If it also happens for smaller projects, then it could be a Clojure or Java environment or tool out of date (or something very new, eg. java 21). Or it could be a neovim config issue or version of neovim (I think I have neovim 0.9.2). I usually update the neovim plugins once a week, as there are regular improvements.

This is more of a hassle for specific, larger projects, hence I felt like it would be useful to see a progress bar, but most of the time it's alright.

Yes, it makes sense if its mostly larger projects, as there is more work to do with the analysis. Keeping the project open in neovim is probably the only way to avoid it (if memory allows)... unless someone buys you an even faster laptop over the winter holidays 🧑‍🎄

Not really, I simply enabled the plugin and didn't need any config changes

It feels marginally better with it disabled. But in my case the problem is just that the project is really big.

Unfortunately I havent worked out how to enable the zipPlugin... so jars remain broken for me... Nothing on the internet and neovim docs only show vim script examples 😞

I tried adding an autocmd but that didnt work...

vim.api.nvim_create_autocmd("FileType", {
        group = vim.api.nvim_create_augroup("comment_config", { clear = true }),
        pattern = { "jar" },
        callback = function() vim.zip.Browse "<amatch>" end,
        desc = "Java archives jar opened as zip files",
      })

The only config change I did was to remove zipPlugin from disabled_plugins in init.lua:

-- Configure require("lazy").setup() options
  lazy = {
    defaults = { lazy = true },
    performance = {
      rtp = {
        -- customize default disabled vim plugins
        -- disabled_plugins = { "tohtml", "gzip", "matchit", "zipPlugin", "netrwPlugin", "tarPlugin" },
        disabled_plugins = { "tohtml", "gzip", "matchit", "netrwPlugin", "tarPlugin" },
      },
    },
  },

Oh, I see. I should have spotted that. Thanks for letting me know.