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

61–70 of 229 posts

Re: How LSP could have been better

#61

Post by fiddlerwoaroof »

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…

The advantage here is this enables some interesting workflows, like “show me this method and every definition that overrides it in a single view” or “show me this method and all the methods it calls directly”. So you can project the interesting part of your code base into a temporary editor buffer and then edit it and the language server takes care of persistence.

Also, it ends the formatting wars because the in-repository format is disconnected from the user’s preferred format.

Re: How LSP could have been better

#62

Post by mardifoufs »

marwis wrote: post #58
kstrauser wrote: post #52

Earlier quoted context omitted.

That’s the part I vehemently disagree with. There are servers written in a whole lot of languages. I’d bet there are Java servers written in Java. How are you going to link that into an editor written in C? What if the server’s written in Python? A shell script (crazy but legal!)? And even if you solve all of those for C, what if you want to write an editor in Swift. Now you have to implement all those shared library…

Use COM or something like it

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

Re: How LSP could have been better

#63

Post by jenadine »

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…

Imho it should be the other way around: the editor knows about file layout and everything, and the language server queries the editor when it needs contents for a specific file. Unfortunately the LSP don't have calls to query contents.

The rationale is that only the editor knows what files are open and modified. Also we can imagine scenario where the editor and the language server are on different remote (eg GitHub codespace or the browser version of vscode. The language server could be a wasm build running where the editor is running, but the editor may access files in a remote server, or vice versa)

Re: How LSP could have been better

#64

Post by akhosravian »

__MatrixMan__ wrote: post #29

I hope we're nearing the end of the era where we're editing text in a bubble of tooling that understands ASTs but has to map everything back to text. I look forward making tabs vs spaces a viewer setting and not an author choice.

Tabs vs spaces has been a viewer setting for decades for tab users.

Re: How LSP could have been better

#65

Post by blackoil »

bumbledraven wrote: post #25

Jonathan Blow criticized the performance and complexity of LSP in his talk at DevGAMM 2019 titled "Preventing the Collapse of Civilization" (timestamp 42m26s; https://youtu.be/pW-SOdj4Kkk?t=2546 ): > In the programming language world, there's this thing called Language Server Protocol that is pretty much the worst thing I've ever heard of. There are proponents of this all over, building systems for it right now that…

Sounds like a cultist who people listen because of their need to be angry at someone. Even after cleaning, this is a word soup with little substance.

LSPs solves two "made-up" problems. Editor and LSP team can be different and independent. Go teams work on LSP without actively collaborating with VSCode team for feature and release. Second, both can run at different places, it allows for things like devcontainer and Codespace. code is built/run on some remote server while IDE is running on local.

Re: How LSP could have been better

#66

Post by marwis »

mardifoufs wrote: post #62
marwis wrote: post #58

Earlier quoted context omitted.

Use COM or something like it

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).

Re: How LSP could have been better

#67

Post by smacke »

kstrauser wrote: post #14

I’m fighting with it right now. LSP specifies several configuration mechanisms but there isn’t a “blessed” one. This is a pain point because: I want to write Python. There’s one FOSS language server (pylsp) that’s a better fit for my needs than the other Python servers. I want to use a certain commercial editor. The editor and the language server don’t share a common configuration method. Ergo, I can’t use the editor…

Have you opened an issue against https://github.com/python-lsp/python-lsp-server? I'm an occasional contributor for easy fixes; if your fix is easy chances are it would get picked up.

Re: How LSP could have been better

#68

Post by kstrauser »

smacke wrote: post #67
kstrauser wrote: post #14

I’m fighting with it right now. LSP specifies several configuration mechanisms but there isn’t a “blessed” one. This is a pain point because: I want to write Python. There’s one FOSS language server (pylsp) that’s a better fit for my needs than the other Python servers. I want to use a certain commercial editor. The editor and the language server don’t share a common configuration method. Ergo, I can’t use the editor…

Have you opened an issue against https://github.com/python-lsp/python-lsp-server ? I'm an occasional contributor for easy fixes; if your fix is easy chances are it would get picked up.

I came in at the tail end of https://github.com/python-lsp/python-lsp-server/issues/195. The possibility of me sponsoring a fix came up, and I’m on board with it, but the other contributor never replied.

Re: How LSP could have been better

#69

Post by inferiorhuman »

mardifoufs wrote: post #27
sillysaurusx wrote: post #26

Earlier quoted context omitted.

Count me among the UTF-8 everywhere absolutists. There are two ways to encode text: UTF-8, and a worse choice. But I wouldn’t be annoying about it. I’d just tut tut from afar. (Though if the decision is still up in the air, I’d argue as passionately as any preacher to persuade our fellow devs to adopt our lord and savior UTF-8 into their hearts and minds.)

Yeah I would absolutely take utf8 everywhere. I hate dealing with anything else. But I think the worst part was that the maintainer was clear that he/she wasn't debating this on a technical level. Like, they weren't trying to decide which encoding was better. From what I understand it was more about how best to deal with the (at the time) current design choices without breaking the current implementations, and feedba…

I'm inclined to agree that some manner of backwards compatibility is important. A middle ground with a path towards exclusive UTF-8 use seems like a fine compromise. However three things come to mind:

* LSP is being used outside of VSCode, and while UTF-16 may be helpful in that case it's a hinderance for others.

* Institutional knowledge of UTF-16 ain't great at Microsoft either. Github broke rendering of multibyte characters and it took a random GH user to the devs explain how multibyte characters and strings interact in Javascript before that got fixed.

* [insert lots of handwaving about the downsides of electron]

Re: How LSP could have been better

#70

Post by raincole »

kstrauser wrote: post #52
raincole wrote: post #44

Earlier quoted context omitted.

He is trying to say that LSP should be implemented as a set of libraries (like liblsppython.so). Your editor compiles with these libraries and provide API for plugin authors. It's not unreasonable to expect an editor's developers to know how to link a native library.

That’s the part I vehemently disagree with. There are servers written in a whole lot of languages. I’d bet there are Java servers written in Java. How are you going to link that into an editor written in C? What if the server’s written in Python? A shell script (crazy but legal!)? And even if you solve all of those for C, what if you want to write an editor in Swift. Now you have to implement all those shared library…

> There are servers written in a whole lot of languages.

I believe his opinion is that there shouldn't be LP (since he's against to use servers I remove the S from LSP) written in language that can't be compiled to xxx.so. We're talking about Jonathen Blow after all.

It make sense if you view LP as a part of an editor. But in our reality the language servers are often maintained by that specific language's community, not the editor devs, so it's probably not the best idea to expect them all to be willing to write in low-level language.

Post reply on HN