61–70 of 83 posts
Earlier quoted context omitted.
Here is how Lucid implemented their C++ knowledge repository for Energize C++. "Foundation for a C++ Programming Environment", chapter 7, Protocols https://pdfs.semanticscholar.org/84a4/8824fc7dd872414efa0ad6... And how it looked like with their Emacs customization in 1993 on UNIX. https://www.youtube.com/watch?v=pQQTScuApWk
Lucid went bankrupt as far as I remember :)
Earlier quoted context omitted.
Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.
With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language. While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST. So LSP actually leads to more duplicated code and worse editors. VS Code will never be able to match the functionality of IDEA unless each language serve…
https://github.com/Ruin0x11/intellij-lsp-server
That being said, as an implementor I'm finding cases where LSP's feature set is underdeveloped. For example, there is nothing in the spec to account for renaming files, so I can't put in my rename action without the behavior being incorrect (because if you rename a class in Java you have to rename the corresponding file, which IDEA handles). Also some things require custom LSP requests, like getting the list of build configurations to run. I think this is a product of the Java support in IDEA being so much more comprehensive than anything in LSP so far. But hopefully as the spec is improved these issues will be worked out
Earlier quoted context omitted.
Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.
With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language. While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST. So LSP actually leads to more duplicated code and worse editors. VS Code will never be able to match the functionality of IDEA unless each language serve…
Earlier quoted context omitted.
Just because Apple is the first doesn't mean there won't be others. Maybe others have not materialized because the upfront cost of updating clangd was judged too high. JSON-RPC has several alternatives that very large software companies have vested interests in: gRPC and XPC. You seem more knowledgeable of these technologies than I am, though. It just seems to me a good thing that 1) Apple, and consequently, all iOS…
My point was precisely that plenty of languages have LSP implementations at this point, an f even in those, nobody has cared much to try to find an alternative to json rpc. As for 2, all I'll say is based on history in llvm projects, I'm not anywhere near as optimistic as you. The history here is simply not one of all great things. The PR is, but the reality is much more mixed (some really great things, some really n…
Earlier quoted context omitted.
And no other editor can implement IDEA’s feature set except from scratch. What a mess.
Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.
Is your complaint that they're not iterating fast enough? Because this is something I'd prefer they take their time and get it right, especially once we get past the low-hanging fruit and into complex things like debugging.
Earlier quoted context omitted.
With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language. While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST. So LSP actually leads to more duplicated code and worse editors. VS Code will never be able to match the functionality of IDEA unless each language serve…
You mean, with common IDE plugins, you end up with one implementation of refactoring functionality per IDE . That's what's being avoided here (because, for one thing, there are far more IDEs than you think, and they don't deserve to be second-class citizens.)
Just like LSP. Just a more intelligent protocol.
You have one implementation of refactoring, instead of, as today, one per language.
Earlier quoted context omitted.
Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.
LSP is already on version 3.7, and publishing an update every few months: https://microsoft.github.io/language-server-protocol/specifi... Is your complaint that they're not iterating fast enough? Because this is something I'd prefer they take their time and get it right, especially once we get past the low-hanging fruit and into complex things like debugging.
Language servers should expose an AST, not some actions. Language Servers shouldn't even know where the cursor is — or how many there are.
With a proper LSP, you can also write a linter just by using the protocol, you can call the same action on a thousand places at the same time, and the refactoring functionality is implemented only once, and reused everywhere.
The entire design of LSP is flawed.
Earlier quoted context omitted.
Oh, you're right. We should just dump all other editors and use IDEA. /s
Or maybe we should build an LSP that exposes an AST in a way that is more useful to IDEs, like IDEAs plugins do today. In fact, the code in IDEA that does this is open source, so you can start with it, and build a better LSP based on it.
Earlier quoted context omitted.
My point was precisely that plenty of languages have LSP implementations at this point, an f even in those, nobody has cared much to try to find an alternative to json rpc. As for 2, all I'll say is based on history in llvm projects, I'm not anywhere near as optimistic as you. The history here is simply not one of all great things. The PR is, but the reality is much more mixed (some really great things, some really n…
You don't think apple's support of llvm and clang has been important to the project? That's REALLY pushing it.
Heck, last time i asked him (a few months ago), even Chris Lattner agreed with my view, and he used to run his stuff at Apple, so i don't think it's unreasonable.
I think it's perfectly okay to be cautiously optimistic instead of fawningly happy.
Do you actually have data or a real argument you'd like to use to suggest otherwise (IE that it's been all overwhelmingly positive?)