add lsp-client

[ners]

We've implemented this LSP client for use in https://github.com/ners/dosh. It has all the features we wanted, so we thought to share it upstream.

cc @vkleen

[michaelpj]

Thanks for offering! I'm a little unsure what this does. If I understand it right, this is a Haskell implementation of the client side of the interaction, similar to what lsp-test does?

Sadly, at the moment we're quite lacking in maintainer bandwidth. lsp-test (which has similar aims) is particularly neglected at the moment. So I'm reluctant to take in more code unless you're definitely going to maintain this! And if it is duplicating ideas from lsp-test, I would be very keen to actually make lsp-test use it, rather than having two implementations of the same ideas.

[ners]

Hey @michaelpj!

If I understand it right, this is a Haskell implementation of the client side of the interaction, similar to what lsp-test does?

You're right, this is an implementation of an LSP client.

I would be very keen to actually make lsp-test use it, rather than having two implementations of the same ideas

It is indeed in part inspired by lsp-test, but it has different design considerations that make it more appropriate for real world applications such as editors. I didn't want to rearchitect lsp-test itself for that reason, but offer lsp-client as a different library.

It would be possible to remove much of lsp-test's internal implementation to make it call lsp-client while keeping the API the same for existing users. This would take some care effort which I'm not sure would be as worthwhile as simply letting those users slowly switch over to lsp-client if they want, fixing issues as they arise.

I'm reluctant to take in more code unless you're definitely going to maintain this

I certainly intend to continue maintaining this, as I also use it in some of my projects. It would be easy enough to host it in my own namespace (i.e. ners/lsp-client), but I think it morally belongs here.

I'd be happy to also remove some of the duplication between lsp-test and lsp-client, if we can agree on a clear plan for that. However, I'm not keen on getting rid of a separate client library, because I find it semantically inappropriate to use a test suite as an application client.

[michaelpj]

I certainly intend to continue maintaining this, as I also use it in some of my projects. It would be easy enough to host it in my own namespace (i.e. ners/lsp-client), but I think it morally belongs here.

I guess what I'm saying is that there's a bit of a Conway's Law thing here, i.e. the problem is more about who's going to do the maintenance. As it is, I'm almost tempted to split out lsp-test because I don't really have time to give it attention apart from keeping it compiling :(

So I'm very selfishly worried about things that make the maintenance worse. Hence why I would be much happier if it let us get rid of a bunch of code from lsp-test: then that would be plausibly positive in any case.

However, I'm not keen on getting rid of a separate client library, because I find it semantically inappropriate to use a test suite as an application client.

To be clear, I was thinking of it the other way around: lsp-test could depend on lsp-client, because it is a kind of client.

If you don't mind, maybe we could leave it separate for a bit, and if you're still actively interested in it in a while then revisit it?

[ners]

I've published the package separately here: https://github.com/ners/lsp-client And it is now on Hackage! https://hackage.haskell.org/package/lsp-client

I'm closing this now, and will open a new PR with a refactor of lsp-test.

[michaelpj]

Thanks! Really happy to see more people working in this area :)