Barebones LSP for integration testing

[kirawi]

I think it would be a good idea to test our LSP code by having a barebones LSP with some helper functions. Something like this could have caught #9429 if we had a test where we have some diagnostics, e.g. helper_lsp.set_diagnostics(&[(0, 0, "diagnostic here")]) and tested if it appeared in the document itself.

[Omar-Elrefaei]

Is this still relevant in light of this comment? #6486 (comment)

I'm very wary of adding integration tests against a language server. ....... On balance I don't think LSP integration tests are worth their added weight and I would prefer we test LSP features manually.

If not, I might be interested in taking this on.

[the-mikedavis]

The example of this that I think could work is a language server for Steel (see #8675). If we decide to bundle a langauge server for Steel out of the box (i.e. provide it with/within the Helix package) then it would make sense to use it for testing as well.

Writing a custom language server just for testing though I don't think adds enough value to justify its weight. I expect that it wouldn't be a trivial amount of code at all and that it would rarely catch places where we violate the spec or behave improperly. If the same person implements a new LSP feature in Helix and in the testing language server I don't think it would catch many bugs.

A big part of the value of testing external language servers like rust-analyzer or gopls for example would be that they wouldn't make the same assumptions about the LSP spec as us or about the exact behaviors of the client. Though as I said in the linked comment I don't think it's worth testing external language servers either since there are a number of drawbacks to adding a dependency like that to the test suite.

[estin]

The feature to bundle some default language servers may unlocks other features like #1015 and #11660

In the way to not built-in to the Helix "core", but distribute them as "sidecar" of Helix (relevant to #10129)