You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Language Server Protocol defines a cross-editor protocol to obtain rich language features from an external source. Adding support for this to CodeEdit would make it far simpler to port language extensions from other IDEs (especially VSCode), making everyone's life easier :p
I work on two libraries related to Language Server Protocol that could be helpful.
LanguageServerProtocol is low-level protocol support. LSP has a very large spec with a huge amount of types, not all of which map nicely to Swift. This lib wraps up all that.
LanguageClient is a much higher-level abstraction that supports client-server interactions, as well as transparent server restarting.
Now, if you are thinking of some kind of VS Code extension interoperability, I'm not sure how much these will help, as all the VSC stuff is implemented in JavaScript.
Reacted by Satish Babariya, Freya Alminde, Jeff L., tbd61 and Marco Vitale
changed the title [-]Suggestion: Implement Language Server Protocol for extensions[/-][+][FEAT] - Suggestion: Implement Language Server Protocol for extensions[/+]on Mar 21, 2022
@matthijseikelenboom I don't think any one person should be responsible for spearheading this. I don't think anyone has time to tackle this huge task that is before us alone. Even if they did, it is not a good idea to work independently on this without collaboration with the rest of the community. It needs to be a group effort.
After carefully agreeing together on an approach, it might be helpful to discuss each piece of work required to get this working and document what is agreed upon as a community. We should divide this into small pieces so no one single person does not feel like they need to tackle big chunks of work alone.
Lots of great links and libraries. Will be going through all of these. I agree, fleshing out the extensions first is necessary. I'll take notes from the VSCode implementation and then study what we currently have and what we need.
@mattmassicotte It's not so much security, but more the problems that could occur if you just load a bundle in Swift on macOS. It's the whole dealing with XPC connections and sandboxing. When using a VM, you don't have that problem. It's handled by the VM.
@matthijseikelenboom oh interesting so when you load code into a Java/C# process that code does not have access to the full VM environment that loaded it? I didn't realize it provided that kind of isolation!
@mattmassicotte Okay so, I went and look into it further, in Java's case. I asked some of my senior (for a lack of a better word) colleagues, and apparently I'm wrong 😅. It seems it's not default behavior, but it's achievable with OSGi. (In my defense, I thought it would be default behavior to load it in isolation, because it was explained in OCP. Assuming that is best practice)
This seems a hefty feature, but appears to be a blocker for a ton of interesting functionality. Given there's been no updates in 8 months, I assume this is stalled.
Is this actually in progress and I just need to monitor elsewhere? (I only learned about CodeEdit today, so sorry if I'm unfamiliar with the Org Structure and communication norms)
Note: I found this ticket because it blocks: Github Copilot Support CodeEditApp/CodeEdit#1182, and that would be the unlock that moves me from VSCode to CodeEdit for most projects!
@fbartho it is currently being worked on by @FastestMolasses. We need to make a few architectural adjustments so we can finish. This is our next milestone and our biggest priority for CodeEdit at the time of writing.
Reacted by Frederic Barthelemy, Alex Ketch, Teddy ROGERS, Marco Vitale, Rui Monte, Andrea Calabrò and Fatih Yılmazer
Also, please do not download-and-install LS without explicit confirmation, just use already existing LS pointed by user. Or make that downloading optional and disablable globally. Please 🙏
Activity
mattmassicotte commentedon Mar 20, 2022
I work on two libraries related to Language Server Protocol that could be helpful.
LanguageServerProtocol is low-level protocol support. LSP has a very large spec with a huge amount of types, not all of which map nicely to Swift. This lib wraps up all that.
LanguageClient is a much higher-level abstraction that supports client-server interactions, as well as transparent server restarting.
Now, if you are thinking of some kind of VS Code extension interoperability, I'm not sure how much these will help, as all the VSC stuff is implemented in JavaScript.
[-]Suggestion: Implement Language Server Protocol for extensions[/-][+][FEAT] - Suggestion: Implement Language Server Protocol for extensions[/+][-][FEAT] - Suggestion: Implement Language Server Protocol for extensions[/-][+][FEAT] Language Server Protocol[/+]austincondiff commentedon Mar 25, 2022
Relevant links
[-][FEAT] Language Server Protocol[/-][+]✨ Language Server Protocol[/+]austincondiff commentedon Jun 1, 2022
Where are we on this issue? What do we have left to call it done? It may be good to define this issues scope.
@lukepistrol does this tie into what you are working on in the new editor?
lukepistrol commentedon Jun 1, 2022
@austincondiff I have yet to read into the LSP stuff. At some point I'm sure this would get implemented into
CodeEditTextViewthough.17 remaining items
austincondiff commentedon Jul 19, 2023
@matthijseikelenboom I don't think any one person should be responsible for spearheading this. I don't think anyone has time to tackle this huge task that is before us alone. Even if they did, it is not a good idea to work independently on this without collaboration with the rest of the community. It needs to be a group effort.
After carefully agreeing together on an approach, it might be helpful to discuss each piece of work required to get this working and document what is agreed upon as a community. We should divide this into small pieces so no one single person does not feel like they need to tackle big chunks of work alone.
FastestMolasses commentedon Jul 19, 2023
Lots of great links and libraries. Will be going through all of these. I agree, fleshing out the extensions first is necessary. I'll take notes from the VSCode implementation and then study what we currently have and what we need.
matthijseikelenboom commentedon Jul 21, 2023
@mattmassicotte It's not so much security, but more the problems that could occur if you just load a bundle in Swift on macOS. It's the whole dealing with XPC connections and sandboxing. When using a VM, you don't have that problem. It's handled by the VM.
mattmassicotte commentedon Jul 21, 2023
@matthijseikelenboom oh interesting so when you load code into a Java/C# process that code does not have access to the full VM environment that loaded it? I didn't realize it provided that kind of isolation!
matthijseikelenboom commentedon Jul 21, 2023
@mattmassicotte Okay so, I went and look into it further, in Java's case. I asked some of my senior (for a lack of a better word) colleagues, and apparently I'm wrong 😅. It seems it's not default behavior, but it's achievable with OSGi. (In my defense, I thought it would be default behavior to load it in isolation, because it was explained in OCP. Assuming that is best practice)
mattmassicotte commentedon Jul 22, 2023
Ok super interesting, and thanks for following up @matthijseikelenboom! I know nothing about Java.
fbartho commentedon Mar 22, 2024
This seems a hefty feature, but appears to be a blocker for a ton of interesting functionality. Given there's been no updates in 8 months, I assume this is stalled.
Is this actually in progress and I just need to monitor elsewhere? (I only learned about CodeEdit today, so sorry if I'm unfamiliar with the Org Structure and communication norms)
Note: I found this ticket because it blocks: Github Copilot Support CodeEditApp/CodeEdit#1182, and that would be the unlock that moves me from VSCode to CodeEdit for most projects!
austincondiff commentedon Mar 23, 2024
@fbartho it is currently being worked on by @FastestMolasses. We need to make a few architectural adjustments so we can finish. This is our next milestone and our biggest priority for CodeEdit at the time of writing.
Multiple Highlighter Support (#273)
boozook commentedon Nov 28, 2025
Also, please do not download-and-install LS without explicit confirmation, just use already existing LS pointed by user. Or make that downloading optional and disablable globally. Please 🙏
PiotrBaczkowski96 commentedon Dec 17, 2025
Hi, Is it being worked on?