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

81–90 of 229 posts

Re: How LSP could have been better

#81

Post by jhoechtl »

raincole wrote: post #7

Recently I stumbled upon this issue: https://github.com/joaotavora/eglot/discussions/1127 I don't know enough about emacs and LSP to see the full picture, but it seems that both eglot's and corfu's maintainers, assumably very competent programmers, can't find a solution for this. I only skimmed the thread. My understanding is that LSP dumps a long list of completion candidates at once and they can't decide a cache st…

I wonder if this is still the case as most comments petered out end of March. There was a nasty bug discovered in Emacs JSONRPC-Library, which did cause spurious LSP connect errors and likely other issues in LSP server communication

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=8bf4c...

Do note that many users might have not been aware of this issue. The fixed library is part of Emacs 29. If you are not on Emacs 29 you might pull in a more recent JSONRPC-package from ELPA in which case it will shadow the inbuilt/pre-shipped library.

Re: How LSP could have been better

#82

Post by School-Cotton »

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’s true in the sense that every invocation takes arbitrarily long and can fail, which isn’t really true for normal libraries.

Re: How LSP could have been better

#83

Post by pxc »

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.

Re: How LSP could have been better

#84

Post by mfashby »

__MatrixMan__ wrote: post #53
ianlevesque wrote: post #36

Earlier quoted context omitted.

Agreed. Even beyond that it would be great for merging & conflict resolution too.

Right. Line-wise diff is such a crude instrument.

You can already get some tools e.g. https://difftastic.wilfred.me.uk/introduction.html which try to do semantic rather than purely textual diffs

Re: How LSP could have been better

#85

Post by fiddlerwoaroof »

jenadine wrote: post #63
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 c…

Well, a lot of this is that I think files are a bad way to represent code. You really want something more shaped like a database that allows for multiple views into the same code. Git would for serialization, but the source of truth should be inside the language server and either the files or the repository.

Re: How LSP could have been better

#86

Post by fiddlerwoaroof »

zarzavat wrote: post #71
fiddlerwoaroof wrote: post #56

Earlier quoted context omitted.

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 hav…

I want a system more like Bank Python[1] or Unison[2] or Pharo Smalltalk[3] that gets us beyond the idea of "code in files". And I have plans to build this on top of Common Lisp + SLIME

[1]: https://calpaterson.com/bank-python.html

[2]: https://www.unison-lang.org

[3]: https://pharo.org

Re: How LSP could have been better

#87

Post by globular-toast »

akhosravian wrote: post #64
__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.

Exactly! A tab is literally "1 level of indentation". You can render that one level any way you like.

Unfortunately, though, everyone who has used tabs got bitten by stupid text editors that don't make it obvious whether you've used a tab or a space and substitute a tab for any run of 8 spaces. So if you're aligning an argument list you'll get a mixture of tabs and spaces. Everyone got bitten by this once back in the day then switched tabs off forever. They then switched tabs off in the text editors that the next generation are using.

Re: How LSP could have been better

#88

Post by runeks »

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.

Hovering over the name of a variable in Haskell shows the type. It sounds like your OCaml LSP server just hasn't implemented this yet.

Re: How LSP could have been better

#89

Post by kstrauser »

moring wrote: post #80
jcrites wrote: post #72

Earlier quoted context omitted.

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 IM…

Security, too. If I’m editing a .env file with a bunch of passwords in one buffer, or maybe some sensitive data I copied and pasted into an empty text window I’m using for temporary notes, I don’t necessarily want some random code written by some 3rd party running in the same process space. I mean, most of userland is pretty much written by various random people already, but I might trust a language server to tell me that I forgot a semicolon in a shell script without trusting it with the contents of /etc/shadow.

Re: How LSP could have been better

#90

Post by alexvitkov »

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…

Frankly, if your language can't compile a .so/.dll that can interact with the rest of the system in a sane way, use a better language.

I used to disagree with Blow on this point, as stdin/stdout communication really has the arguable advantage that you can write your Brainfuck LSP in Brainfuck, but I've spent way more time than I find reasonable over the last few years dealing with the consequences of the LSP model - tweaking environment variables, paths, command line arguments for the server, server crashes, mismatches of server version vs the compiler, the client picking the wrong server executable, system-provided language vs downloaded by VS code extension......

I'd rather just drop a dll in Plugins/ and be done with it.

Post reply on HN