refactor(lsp): mark server_ready function as deprecated

[glepnir]

window/progress not part of lsp spec. we shouldn't have this handler. Consider it already used in some user config or plugin. So mark as deprecated and remove in next version

Fix #23511

[clason]

This may be throwing out the baby with the bath water. Presumably, plugins need or at least want a "server ready" function. Just because this request is fake doesn't mean we can't use another, valid, request, or some other way of checking whether a server is ready to answer requests.

[glepnir]

this notify does not exist in lsp spec. you can't find it on spec. don't know why we keep this handler?

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/

[clason]

Again, it's about the server_ready function, not the specific window/progress request. We can keep the function and just use a different, valid, request.

(To be clear, this is not a handler for a message. This is a utility function that sends a message -- but that is an implementation detail that can (and should) be changed.)

[glepnir]

there has $/progress in lsp spec. if want make sure the server ready why don't use this ?

[clason]

So this is just a typo, or someone forgot to adapt to changes in the spec. Why not just fix that then?

[glepnir]

upport server progress notifications via $/progress, removing support for the non-standard window/progress (#545).

a server update change log. and this notify looks like never exist in lsp spec or only in 2018? idk just search it only on some old codes like rls. I check some servers source code they don't handle this notify. so this mean if you call server ready an error in your log.

Things that are not standard should not remain in neovim core. Anyone who needs to call this function should know what it's doing. If you confirm whether the server is ready, you should use the progress provided by the specification, right?

feel free to close or merge . because I never used this 😃

[mfussenegger]

Given that there really is no good alternative in the specification to detect if a server is ready I'm inclined to merge this. If my interpretation of the spec is correct, after the initialize handshake a server should be ready to serve requests.

I think what's an issue with many language servers is if they've finished analysing the workspace, but given that edits can always re-trigger analysis/builds that's always a catch-up game, and it's also unclear what an editor should do if the server is still processing changes. It is also not a simple ready/not-ready, because depending on the implementations they can serve some requests with sensible results, some with outdated, some not at all.

I'll wait a bit longer before merge to give others a chance to comment.

[A-Lamia]

I was using that function to check if LSP's where attached so i could run some autocommands, what would be a good replacement for this now ?

[clason]

The LspAttach event.

[A-Lamia]

Isn't that only used to run the command on attach ? I was using it more as a check on ModeChange.

EDIT: dw just looked through docs and came up with an other way i guess ty.

[justinmk]

Documented in #24061