Hacker News Reader

Comment by jmcphers | Hacker News Reader

It is true. Some things you can't build in extensions for VS Code are:

- 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.

View on HN

Another one is custom CSS (though it doesn't look like positron does that.) You can change styling properties like spacing and weighting as well.

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?

What's different between Postiron's core language system and language systems like LSP and DAP?

It's a higher-level construct. LSP and DAP are both used by Positron! But they're a pretty small subset of everything you actually want to do with a language. For example:

- 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.

Mmh, all of these examples were done with vscode jupyter extensions... So they're definitely doable without forking.

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.

Reply on news.ycombinator.com