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…
Apple's investment into Clangd and refactoring tooling
31–40 of 83 posts
Re: Apple's investment into Clangd and refactoring tooling
#32I hope that it also means there will be Apple-provided LSP server for Swift soon.
Re: Apple's investment into Clangd and refactoring tooling
#33Earlier 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…
Re: Apple's investment into Clangd and refactoring tooling
#34I'm assuming this is the "LSP" discussed? https://microsoft.github.io/language-server-protocol/ Mapping json-rpc onto xpc... Sure why not
Re: Apple's investment into Clangd and refactoring tooling
#35Earlier 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…
Re: Apple's investment into Clangd and refactoring tooling
#36I'm assuming this is the "LSP" discussed? https://microsoft.github.io/language-server-protocol/ Mapping json-rpc onto xpc... Sure why not
Are there any other implementations of LSP by other orgs?
Re: Apple's investment into Clangd and refactoring tooling
#37I'm glad to see that Apple is putting work into making their tooling better and easier to work with, but I'm still not clear on the benefits of this change. Would someone care to enlighten me? Currently, the benefits of libclang that I see are that I can easily drop it into a project without requiring a lot of dependencies, and I don't need to figure out how to get permission to run different processes and manage int…
Clangd already exists (it was contributed and mainly maintained by Google, IIRC), and works great. It supports LSP, and works fine with vscode.
What apple is investing in is making it their default tooling.
So the benefits of this change are exclusive to apple xcode (ATM) :)
The benefits to using clangd in general are (among poher things) editor agnosticism and scaling.
If everyone uses libclang, libclang must scale to every codebase (or a least, the interface, and then you'd have to replace/relink it).
If everyone uses LSP, you just need something that speaks LSP, and scales to your codebase.
At the scale of Google's codebases, for example, the first is untenable, the second is doable.
Re: Apple's investment into Clangd and refactoring tooling
#38I tried building Clangd in trunk but failed to build.
Re: Apple's investment into Clangd and refactoring tooling
#39I'm assuming this is the "LSP" discussed? https://microsoft.github.io/language-server-protocol/ Mapping json-rpc onto xpc... Sure why not
Woah I had never seen this before. That's really cool. So in theory you can make your own editor and provide a ton of IDE-like features by communicating with this server? Are there any other implementations of LSP by other orgs?
Re: Apple's investment into Clangd and refactoring tooling
#40Clangd already exists. It already supports LSP. It is already part of the llvm project. It was written by !Apple, and used by a wide number of people.
(I want to make sure these people still get credit, i already see people in this thread thanking apple for supporting LSP, which is not actually what happened).
What apple has proposed contributing is: Making clangd work with xcode, and extensions to LSP.
This is great (as long as the second ends up standardized over time).
But the benefits people listed here so far already exist in clangd. The main benefit to work is "xcode support" and "better refactoring" which is awesome :)