Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How LSP could have been better

matklad.github.io

Post reply on HN
Print view View original

71–80 of 229 posts

Re: How LSP could have been better

#71

Post by zarzavat »

fiddlerwoaroof wrote: post #56
slimsag wrote: post #34

Earlier quoted context omitted.

That's exactly how LSP is designed. The editor e.g. requests 'the user is hovering over code , what should I show?' and the server responds with some Markdown text. Or 'the user wants to navigate to the thing under their cursor , where should I go?' and the server responds with a file/line. Once you try to use LSP for anything not in that form.. it's not so fun.

No, this is the opposite of how LSP is designed: LSP assumes the editor is looking at a file and this results in a complicated sync dance between editor state and file state. I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself. As far as I know, the only…

> I want the editor to look at temporary buffers served up from the language server and have the code be “written” by sending the temporary buffer back to the language server which handles writing it out to files itself.

I don’t think any editor would want to accept this workflow. The biggest issue is that writing is reputation-critical, if the editor writes to the wrong place, or it fails to write when it should have written, then users lose their work which makes them very unhappy. So the editor has to take responsibility for doing the writing, and that is the user’s mental model when they save their work.

Re: How LSP could have been better

#72

Post by jcrites »

mardifoufs wrote: post #59
moring wrote: post #48

Earlier quoted context omitted.

He's saying (without saying it) that LSP is another instance of the "microservices everywhere" hype, and bad for the same reasons -- you have a problem, you try to solve it with a distributed system, now you have two problems and one of them is a set of microproblems. I don't think he is arguing against a standardized interface to language-specific logic, but arguing for that standard to be a library interface, not a…

He doesn't say why a library interface would be better. That's why I'm saying he doesn't even address the main point of LSPs, which is that they came in response to have your IDE or editor maybe-kind of plug into some libraries and wish for the best. Just saying that a library interface would be better because it's less complex is meaningless, when we obviously have not managed to get anything close to that for the p…

I also think it's a bit overblown to call communication with a locally running process a "distributed system". I mean, that's kind of true, but not really any more true than if you were to call having multiple threads in your process a "distributed system".

Re: How LSP could have been better

#73

Post by tjoff »

kstrauser wrote: post #57
duped wrote: post #47

Earlier quoted context omitted.

LSP is a protocol for answering queries about the language model behind the text, not controlling anything about the text itself (expect for auto formatting, but that's a bit special). Those configurations seem to be in scope for the text editor, not the language server. In fact LSP is mostly configuration agnostic. It might use configuration for a particular query like autoformatting, but it's still request/response…

You have to tell the server how to interpret the code somehow. I mentioned line length. In Python, you may want one configurable max for code and another for comments. If you can pass those to the server, it can tell you which lines are too long using the standard mechanism for identifying errors and warnings. Otherwise, the editor would have to know how to parse the code so it could know whether a given line is code…

I get what you are saying, but it still sounds like a linter. And the linter (and syntax highlighting etc.) do need to understand the code - but the LSP is not necessarily the right tool for that.

In many cases the right tool is something like treesitter. Treesitter paired with an LSP is an incredible combination.

But yes, I understand your frustration. And if the best implementation happens to be inside the LSP then so be it.

Re: How LSP could have been better

#74

Post by mardifoufs »

marwis wrote: post #66
mardifoufs wrote: post #62

Earlier quoted context omitted.

What if you are not on Windows? Or if you want to remotely run the language server?

You can implement it ("or something like it") on any system. In fact there is a plenty of those. Remoting isn't impossible either (e.g. DCOM, CORBA, GRPC).

Why not just use a server then? Surely that's less complicated than implementing or even just using CORBA/DCOM?

Re: How LSP could have been better

#76

Post by kstrauser »

tjoff wrote: post #73
kstrauser wrote: post #57

Earlier quoted context omitted.

You have to tell the server how to interpret the code somehow. I mentioned line length. In Python, you may want one configurable max for code and another for comments. If you can pass those to the server, it can tell you which lines are too long using the standard mechanism for identifying errors and warnings. Otherwise, the editor would have to know how to parse the code so it could know whether a given line is code…

I get what you are saying, but it still sounds like a linter. And the linter (and syntax highlighting etc.) do need to understand the code - but the LSP is not necessarily the right tool for that. In many cases the right tool is something like treesitter. Treesitter paired with an LSP is an incredible combination. But yes, I understand your frustration. And if the best implementation happens to be inside the LSP then…

I see your point, too. (And also adore treesitter!)

The examples I gave were around lint-y types of things, but the same problem affects more LSP-y things, too. The link I gave has lots of tweakable knobs for refactoring plugins and other stuff that’s more philosophically in-scope for language servers.

Re: How LSP could have been better

#78

Post by School-Cotton »

Ozzie_osman wrote: post #38

I've read a bunch of articles about LSP, and some of the docs, but still not entirely sure what it is. I mean, abstractly I understand, but to truly understand what it's capable of doing and when I might need to use it... Does anyone have any good pointers?

What do you typically program in?

Re: How LSP could have been better

#80

Post by moring »

jcrites wrote: post #72
mardifoufs wrote: post #59

Earlier quoted context omitted.

He doesn't say why a library interface would be better. That's why I'm saying he doesn't even address the main point of LSPs, which is that they came in response to have your IDE or editor maybe-kind of plug into some libraries and wish for the best. Just saying that a library interface would be better because it's less complex is meaningless, when we obviously have not managed to get anything close to that for the p…

I also think it's a bit overblown to call communication with a locally running process a "distributed system". I mean, that's kind of true, but not really any more true than if you were to call having multiple threads in your process a "distributed system".

It introduces _some_ of the failure modes of a distributed system, like unsynchronized / inconsistent data, but not all, like network failures. I think he does have a point there -- as a user, I should not have to care whether an IDE talks to a library via its API or to a language server via LSP, but here I am, watching WebStorm to act up and complain that the TS language server crashed.

One thing that Blow misses IMHO is to what extent libraries introduce these failure modes _too_: A library can crash as well (and take down the IDE with it), and multiple libraries that deal with the same data can get inconsistent. That's actually a problem of quality control, integrating code from multiple third parties, and so on.

Post reply on HN