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

91–100 of 229 posts

Re: How LSP could have been better

#91

Post by raincole »

jhoechtl wrote: post #81
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 E…

I stumbled upon this issue because my eglot still constantly gets out of sync with LSP. (emacs 29.1, latest stable corfu and eglot)

Re: How LSP could have been better

#92

Post by globular-toast »

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?

For a more succinct answer, I use it for three things: jumping to the definition of a symbol, auto completion of symbols and keywords and showing documentation.

None of this is new. We've had TAGS tables forever. Certain editors would provide the rest for certain languages in language-specific ways. LSP is just a general solution to the any editor/any language problem. It seems to work at least as good and often better than the custom solutions before.

Re: How LSP could have been better

#93

Post by alexvitkov »

valcron1000 wrote: post #42
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…

I don't care how many credentials Jonathan Blow has, this take is pure bs. "we're spending all this time overcomplicating stuff that we used to be able to do in 1960", yet he takes the time to explain "tricks" on how to rename variables [1], while modern tools (not necessarily LSP) let you fly through the code [2]. This is just an "old man rants at cloud" take. 1. https://youtu.be/2J-HIh3kXCQ 2. https://youtu.be/AxxN…

The environments we work in shape our biases and what we find good and bad.

Game programmers spend their careers writing C++ where, yes, you really need tricks like this to rename the variable, as the language is so fucking insane that ALL tooling gets it wrong - and the consequences of getting it wrong can be disastrous.

The most widely used options for C++ are VS's IntelliSense and clangd. IntelliSense is utter garbage, I never trust it for renaming things. clangd is better but can still get things wrong if your build process is complicated your compile_commands.json doesn't perfectly reflect it.

Managed languages have fantastic tooling with perfect context of your project, but they're also managed and are not applicable in a lot of environments.

Re: How LSP could have been better

#94

Post by kmarc »

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.

It's not a problem, in contrary it is good that implementors are pointed to possible code intelligence features that they current IDE's don't provide either.

I read some factual inaccuracies here.

LSP (the protocol)'s main driving force was for a long time TypeScript rather than JS. FYI TypesSript has a stronger type system than Java at this point, and it's LSP server is the most comprehensive and supported way to write TS with.

Another example of an LSP success story is Rust's rust-analyzer. Not to mention that C++'s clangd also became an LSP server many years ago.

All these are strongly typed and bring extra semantics (templates, lifetimes) way beyond other languages.

"query type of symbol" functionality is provided as an example by the textdocument/hover call [1]

But even if this wasn't implemented, the protocol lets any implementor extend the interface with additional / non-standard methods (and clangd did exactly that[2])

It might be that the not-widely-popular ocaml's LSP support is not there yet. Probably it's an open source project, so you can help with the implementation, or at least vote for missing features to be implemented.

[1]: https://microsoft.github.io/language-server-protocol/specifi...

[2]: https://clangd.llvm.org/extensions

Re: How LSP could have been better

#95

Post by sakras »

duped wrote: post #17
dom2 wrote: post #15

One thing that has annoyed me with some personal implementation work is why does DAP use a cosmetically similar but not following spec version of JSONRPC? Why not just use JSONRPC especially considering LSP already does?

Because of organizational disorganization within the VS Code development teams. LSP and DAP are basically the VSCode APIs for implementing language support and debuggers but bolted onto an RPC layer without synchronization or consistency between the people/teams that develop them.

Conway’s law at its finest!

Re: How LSP could have been better

#96

Post by kmarc »

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…

This is incorrect;

The textDocument/diagnostic[1] is far beyond "the language model behind the text" and includes linting which many LSP servers implement (TS and python for example), and it can also happen as a "push" as opposed to "request/response"

[1]: https://microsoft.github.io/language-server-protocol/specifi...

Re: How LSP could have been better

#97

Post by Reisen »

fiddlerwoaroof wrote: post #85
jenadine wrote: post #63

Earlier quoted context omitted.

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.

This is something I have been wanting for nearly a decade. A lot of writing software isn't just implementing your logic and abstractions but actively thinking about how to organize code to the constraints of the filesystem. Having to actively model your modules around file paths, Rust for example tightly binding the use of `mod` to your layout. Refactoring is the same, a non-trivial amount of time on large projects when re-factoring is realising you need to re-organise some module hierarchy and that involves modifying the file system too.

I really dislike this, instead of a fuzzy file finder I want a fuzzy function finder, where all functions are just kept in a database that I can pull into buffers at will. Where hierarchy is only based on the logical structure of your program and the filesystem ceases exist. "New Function" over "New File". You can get the "Fuzzy Function" finder part somewhat with LSP Symbols, but it doesn't get rid of the having to think about files.

Unfortunately I don't think you can get this without first-class support by the language itself, and new languages getting critical adoption isn't a regular thing.

Re: How LSP could have been better

#98

Post by marwis »

mardifoufs wrote: post #74
marwis wrote: post #66

Earlier quoted context omitted.

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?

No it is not (well it might be with antiquated CORBA/DCOM stack but these are just examples, something newer like GRPC would be easier, the point is that it's solvable).

Also the original complaint was about explosion of language combinations and I just pointed the solutions to this are well known.

Re: How LSP could have been better

#99

Post by jesperlang »

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…

Exactly! There is such a shift in paradigm that needs to happen here and the only project I know of that is moving in this direction is Unison.

I don't want to edit a "file", I want to edit these two functions that exist in some module(s), why can't I just see those two?

I constantly jump between many different languages and the cognitive load is noticeable: was it "!=", "/=" or "~="? Why am I writing/viewing ascii art when I'm coding?

If I am most comfortable/fluent viewing python, why can't I view a javascript source as python?

I think the remaining challenge is what sort of projections are the best/most useful? How do we manipulate these projections? I have played around with these ideas and made an AST viewer for the browser where you could configure exactly how a node was represented (using CSS) and navigation was done in block mode (node traversal) but I found it really hard to build an editing experience that felt smooth..

Re: How LSP could have been better

#100

Post by tjoff »

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.

You don't get those features because the OCaml LSP doesn't implement it.

Works fine in other LSPs.

Post reply on HN