A good question. The VS Code extension API is pretty powerful but extensions run separately from the main workbench process and they can't draw any meaningful UI on it. This was a great design decision IMHO as it is the core reason VS Code has a reputation for a minimalist UI and good performance despite being based on Electron.

However it also made it impossible to build the kinds of experiences we wanted to with Positron. Positron has a bunch of top-level UI as well as some integrated/horizontal services that don't make sense as extensions. We built those into the core of the system which is why a fork was necessary.

It's a goal for Positron to be extensible, so it has its own API alongside VS Code's API, and both the R and Python language systems are implemented as extensions.

I'm curious if you would be willing to elaborate on what your plans are for longer term feature parity with vscode? As in I can imagine as vscode receives continued development and new features you will have the development burden of having to integrate these updates into your fork. Are you planning to keep up-to-date with vscode or will the products essentially drift a part over time? If the latter would this mean extension developers have to build separate extensions for your IDE?

We merge upstream from VS Code every month and we plan to keep up to date with it, so extensions will continue to work and we'll continue to inherit new features as they become available.

It's a development burden for sure -- but still an order of magnitude cheaper than trying to build a good workbench surface from scratch.