Comment by elashri
Extracting from cursor team [1]
> VSCode extensions have very limited control over the UI of the editor. Our Command-K and Copilot++ features aren’t possible as extensions. Same for much of what we want to build in the future!
Extracting from cursor team [1]
> VSCode extensions have very limited control over the UI of the editor. Our Command-K and Copilot++ features aren’t possible as extensions. Same for much of what we want to build in the future!
> VSCodium
VSCodium does not do any development but only build VSCode codebase to be without all Microsoft telemetry and proprietary stuff and use open-vsx marketplace.
> VSCode
I will leave it as an exercise to the reader to think of some reasons why would VSCode team refuse to accept such change.
Personally I prefer more forks and new editors. Leaving everything in Microsoft’s hands limits how quickly core features can be added. Let the best editor win.
The issue is that the forks don't have the resources to focus on the security issues as they come up, and as the fork gets further and further away from the main project it becomes harder to merge the changes from the main project.
I don't fancy a future of multiple diverging VSCode forks.
I wonder if they could have created a "Super Plugin" interface instead of a Cursor specific fork and try to get it merged to VSCode or VSCodium or at least keep as a new shared platform for deep customisation instead of balkanisation by everyone interested in doing something similar.