goldsmith.nvim
goldsmith.nvim copied to clipboard
WhoIsSethDaniel
Determine and report when `gopls` is actually ready
gopls can be very slow to respond after initial start. This is due, mostly, to it needing to download required packages for the current module. This can take time (many seconds or even minutes). Goldsmith should be able to report on this intermediate state where gopls is running but is not responding to requests. It should also be able to report when gopls is ready to accept requests.
Could also use a queue that is processed when gopls is actually ready. This can be used in lieu of CursorHold events (which are going to be more expensive).
LspProgressUpdate will work with the caveat that any LSP status plugin that overwrites the status update handler will keep it from working.
Regardless, this is probably the way to go.
ATM it seems that if I have two autocmds (even in different groups) that are User LspProgressUpdate the events are somehow distributed between the two listeners instead of all events going to all listeners. I may be doing something wrong, but I don't see what it is.
This is likely because vim.lsp.util.get_progress_messages can only read the messages once. So FCFS and only one consumer will get the 'done' message.