Comment by a-ungurianu

Comment by a-ungurianu 3 days ago

I’d love a good summary on why Cursor, Void (and I assume other tools) decided to build new editors instead of just extending the incumbents (VSCode extension, Jetbrains plugins).

Is there a technical limitation of the extension APIs or is it easier to “market” a new editor than an editor extension?

While adoption for individuals and small companies might be easy, a lot of bigger places already have other integrations with existing IDEs and displacing those for yet another IDE will be a hard ask

elashri 3 days ago

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!

[1] https://forum.cursor.com/t/why-not-a-plugin/2448/2

Reply View 6 replies

Fluorescence 3 days ago

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.

Reply View | 5 replies
- elashri 3 days ago
  
  > 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.
  
  Reply View | 0 replies
- throwthrowuknow 3 days ago
  
  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.
  
  Reply View | 1 reply
  
  KetoManx64 2 days ago
  
  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.
  
  Reply View | 0 replies
- [removed] 2 days ago
  
  [deleted]
  
  Reply View | 0 replies
- odo1242 3 days ago
  
  This is just Eclipse Theia plugins. In fact, I wouldn’t be surprised if this project is actually Eclipse Theia based
  
  Reply View | 0 replies

[removed] 2 days ago

[deleted]

Reply View 0 replies

andrewpareles 2 days ago

> I’d love a good summary on why Cursor, Void (and I assume other tools) decided to build new editors instead of just extending the incumbents (VSCode extension, Jetbrains plugins).

This is a great question. We think extensions are often buggy (e.g. Copilot, where the selection jumps), or unable to integrate very naturally (e.g. Codeium, other open source extensions). For example, a lot of extensions use the quick pick dropdown for the user to enter a prompt, which feels unnatural. Owning the IDE like Cursor is important to get around these issues, and we think this is why Cursor is so popular.

> While adoption for individuals and small companies might be easy, a lot of bigger places already have other integrations with existing IDEs and displacing those for yet another IDE will be a hard ask

You're right about IDE adoption. We want to build on top of an already-popular to help us reach smaller players, and hopefully we can win over larger companies in the long run with privacy and by centralizing nice AI features.

Reply View 0 replies

[removed] 2 days ago

[deleted]

Reply View 0 replies

[removed] 2 days ago

[deleted]

Reply View 0 replies

maeil 3 days ago

Cody has done exactly what you said, do it through an extension, and is competitive with Cursor. I've been unable to find a reason to use Cursor over Cody given the "fork" drawback. Though I've mostly switched over to Aider.

Someone else mentioned monetization, which may be the real reason.

Reply View 0 replies