fix(helix-lsp): don't panic when lsp capabilities aren't initialised

[rslabbert]

Some language servers don't 100% align with the spec and might start to send commands before the initialization has fully completed. In these cases, it's probably best for Helix not to panic entirely.

I'm not sure if this is the best version of this change (maybe logging a warning would be good), but it converts an outright panic into a no-op, similar to what a lot of the code does when the capability required isn't supported. Happy to work on this if needed.

[pascalkuthe]

Do you have a reproduction case?

I am fairly certain that this is not the right fix. You are changing notifications and requests sent from the client to server here. It's ok to unwrap here because helix will ignore any LSP server until it's finished initializing (capabilities are set by that point).

Any code that somehow obtains a reference to the server regardless and sends a notification/requests to an uninitialized server is buggy/a programmer error and should lead to a panic.

There might be some edgecase where a notification leads to us sending a notification/request back to the server altough I can't really think of a case where this would occur (hence the request for reproduction case). In that case this requests likely need special treatment

[rslabbert]

@pascalkuthe It's quite hard to reproduce reliably, but I've mainly encountered it in the context of clojure-lsp. A similar type of crash was noted on #3389. I can see about working on a reproduction case (maybe with a mock LSP).

My suspicion (given that the cases that I've run into seems to be primarily around starting to edit before the LSP has initialized), is that if the LSP start up times out somehow, another command that was waiting on the initialization notification will proceed. To your point, this is an unexpected state to be in and most likely a bug.

That being said, my logic for this change was to ensure that if something like this happens, the editor won't crash, especially given that the times I've run into it, I've probably been a minute or two into a larger edit. Because of that, I sometimes wait until the LSP is initialised before doing anything to prevent helix panicking.

So I can look for the root cause and a reproduction, but I still think having a non-panic approach to these situations would be good.

[pascalkuthe]

#3389 was different because the crash occurred in an event handler so in core that is run when the server sends a message. This is fundamentally different to the code you are changing here which is used to send a message yo the server.

#7467 should have caught the last cases of panics in the LSP message handles for unitalized servers. If you are still using 23.5 (or were using an older master commit when you last experiences thag) then that could already be fixed.

In general we purposefully panic in codepaths which can onky be reached if invariants are broken since it makes bugs inifunitely easier to track down. Any code that sends a request to an unintalized server is buggy (and it's a very hard to actually do) and should cause a panic so it can be fixed properly.

[rslabbert]

I missed #7467 when I was looking through the issues. I suspect that's what I was running into.

It's good to know about the use of unwrap as a convention here. Thanks for taking the time to review.