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

131–140 of 229 posts

Re: How LSP could have been better

#131

Post by eddythompson80 »

Xophmeister wrote: post #128
throwaway50182 wrote: post #117

Earlier quoted context omitted.

What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…

To be cynical, I guess we're at the "embrace and extend" part; "extinguish" hasn't happened yet, but it could. Microsoft controls the LSP and VS Code is very popular; thus Microsoft has all the leverage in the LSP space. I'm not sure what "going rogue" would look like, on Microsoft's part, but with all the power, it could do so without adversely affecting itself.

To be more cynical all products from all companies are in the “embrace and extend” phase

Re: How LSP could have been better

#132

Post by throwaway50182 »

prometheon1 wrote: post #129
throwaway50182 wrote: post #117

Earlier quoted context omitted.

What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…

What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways. Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes…

By this logic, they are also currently Embracing and Extending Windows, Office, etc. This doesn't make sense to me. It's their original products, not something they embraced and plan on extinguishing.

Re: How LSP could have been better

#133

Post by oaiey »

fiddlerwoaroof wrote: post #12

The way a language server should work, imo, is it holds all the code and serves projections of the code on the fly to the editor. The user of the editor makes changes to the code and commits it back, at which point the language server parses the code and integrates it into the codebase, pretty-printing it to files as necessary for source control. But, the file layout should be an implementation detail that the editor…

Last time I read the LSP specs/repos, there were 2 nuances regarding your statement:

(1) the editor read the files, display then, and then sends changes to the LSP which then mirrors the file to compile, analyze, etc it. The file is never persisted in that stage to the file system (needs to because otherwise no syntax highlighting while editing.

(2) there are conversations about that in both the LSP and Editor space about virtual file systems. Google "language server virtual file system". The core author of the LSP spec has written one issue very related to it.

Re: How LSP could have been better

#134

Post by hardware2win »

junon wrote: post #115

LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP w…

Visual Studio was a meme?

It is still top IDE matched by maybe just JB

Re: How LSP could have been better

#135

Post by nobleach »

junon wrote: post #115

LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP w…

You can say a lot about Microsoft the company. You can even take digs at Visual Studio Code and its "telemetry reporting". But LSP is one of the best things that's come out of that whole ordeal. It's far from perfect. But as a Vim user, we've had nothing this good until now. I used TernJS for JavaScript and some other handy plugins for other language specific stuff... and it was such a pain. LSP made things far more uniform. And they gave it away to the community! They didn't force anyone to use it.

Re: How LSP could have been better

#136

Post by _flux »

pxc wrote: post #83
grumpyprole wrote: post #75

The biggest problem with LSP is that it's a lowest common denominator solution. If I try to edit OCaml using an LSP solution, I don't get features like "query type of symbol", presumably because JavaScript doesn't need it.

Wait, does that feature mean what is sounds like? That sounds too basic to be fundamentally beyond LSP.

Yeah, it sounds like it should support it.

Traditionally though OCaml editor integrations have also supported not only asking just the type of a symbol, but of an expression. I wonder if LSP can do that, because that function needs some interactive scoping of the query, not just a single point, or I suppose it can work if hovering over parenthesis but if precedency needs to be accounted for, it would be difficult to understand what the user wants to see.

I've _really_ enjoyed the expression type queries in the past, but I haven't coded OCaml for a while :/.

Re: How LSP could have been better

#137

Post by junon »

prometheon1 wrote: post #129
throwaway50182 wrote: post #117

Earlier quoted context omitted.

What exactly did they embrace and extend with LSP? And what's going to get extinguished? They created it and others adopted it... They could've simply integrated TypeScript into VSCode using a proprietary protocol to keep people locked to it. Instead they took care to make a well documented and reasonably open protocol that others can use for their own language support, and to integrate TypeScript into other IDEs. I…

What we are seeing now could fit a timeline where Microsoft is doing EEE again, as well as a timeline where Microsoft is trying to change its ways. Building VSCode, LSP and Typescript could still prove to be the Embrace and Extend phase. There are some worrying signs, e.g. many VSCode extensions built by MS don't work on open-source VSCode builds like code-server and VSCodium. From a business perspective, this makes…

Exactly this. It could be either one, but M$ has done zilch to earn goodwill from the community.

Re: How LSP could have been better

#138

Post by junon »

hardware2win wrote: post #134
junon wrote: post #115

LSP is just Microsoft's EEE[0] into the open source space, as they've done with a number of things (including Typescript and buying GitHub/NPM, WSL, etc). Visual Studio was a meme for a long time because it was so heavy and enterprisey, so to capture more market share they made the cool new shiny version VS Code, and wanted to compete with e.g. Atom whilst still having their grip on the ecosystem as a whole. So LSP w…

Visual Studio was a meme? It is still top IDE matched by maybe just JB

Because up until (relatively) recently, you couldn't even compile code on Windows without VS.

Re: How LSP could have been better

#139

Post by lozenge »

the_mitsuhiko wrote: post #43
kstrauser wrote: post #33

Earlier quoted context omitted.

That’s exactly the kind of thing LSP deals with. You have to get those settings into the server somehow, and the main methods are for the editor to send them to the server, or for the server to load them from somewhere in the filesystem or similar. A lot of those settings (like line length) are configured in the editor by the user. It makes a lot more sense to have a mechanism to communicate them over the same protoc…

LSP assumes that there is a higher level editor integration that handles configuration. That’s not ideal but it’s somewhat sensible as different editors will want to expose different ways to configure them.

Ideally, adding an LSP would just be adding a file path to your editor config. This file could contain standard info like supported file extensions, the executable of the LSP, and the parameters to pass the executable. You could also disable/ignore certain features. And, this file would have a common format across all IDEs.

Re: How LSP could have been better

#140

Post by lozenge »

duped wrote: post #47
kstrauser wrote: post #33

Earlier quoted context omitted.

That’s exactly the kind of thing LSP deals with. You have to get those settings into the server somehow, and the main methods are for the editor to send them to the server, or for the server to load them from somewhere in the filesystem or similar. A lot of those settings (like line length) are configured in the editor by the user. It makes a lot more sense to have a mechanism to communicate them over the same protoc…

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…

No, LSP describes what information to present in the editor. For example, Inlay Hints. The user might want to see the type of every inferred variable, or just inferred return types of functions, or nothing at all. LSP needs to consider the user config and only send the info that should be displayed.
Post reply on HN