- core services (Positron's core language system is an API, and R and Python are extensions) - native panes (you can contribute webview panes but they're slow!) - toolbars for other panels, or global toolbars - modal dialogs or any UI other than notifications and quick-pick lists - custom layouts
At a higher level, Positron is a platform that contains data science tools for _other_ extensions to use, and doesn't make sense as an extension itself. The R and Python extensions are the first two we built, but the platform is extensible to other languages.
- discover all the interpreters on the system for the language (e.g. 'find me all the Pythons')
- start an interpreter session for the language
- run a fragment of code in the language and return the result
- get all the variables in the current interpreter session for the language
- view data defined in a particular variable
etc.
We generally try not to invent new protocols; in addition to LSP and DAP, we use Jupyter messages and kernels for most of the above. Positron only has custom protocols/APIs for the bits that are outside the purview of existing protocols.
Not trying to discredit the need for a fork though.
While you can technically do all of your examples (with extensions), it would likely mean that you'd have to either redesign the UX to limit it to where the extensions are good, or live with a somewhat unpolished user flow at times (because they're possible, but maybe not in the way the person imagining the UX wants.
I have a love/hate relationship with the VScode webview panels, but the message handler is not my favorite implementation in the world. I would love a way to send binary data, and get semantic token colors.
The only issue is that when you have a custom build of VScode, you have to manage a fork of VScode, and potentially pull in updates as VScode updates. How do you manage that?