Determine and report when gopls is actually ready

[WhoIsSethDaniel]

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.

[WhoIsSethDaniel]

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).

[WhoIsSethDaniel]

perhaps using LspProgressUpdate event.

[WhoIsSethDaniel]

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.

[WhoIsSethDaniel]

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.

[WhoIsSethDaniel]

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.