[Epic] Extensibility API

[lextm]

I believe a lot of recent feature requests are quite good and some from well-recognized developers in the community, which means SharpIDE started to gain popularity and momentum beyond just a few guys.

It would be beneficial for everyone if there is a standard set of extension API exposed, so that language-specific features (language server, debugger adapters, unit test providers, visual designers) can be supported by their respective extensions and extension authors.

This can free each one from asking the same/similar questions in this main repo, which focuses on IDE shell and C# language support.

Based on the availability of open-source components right now, very soon people can extend SharpIDE to many more languages than @MattParkerDev alone can achieve.

• Language services related
  • [WIP] VS for Windows language extension compatibility test #99, T4/reStructuredText
  • Integration with AXSG toolset to enable XAML language support #97, XAML
  • F# - syntax highlighting #96/Compatibility for F# #18, F# language
  • Compatibility for VB.net #60, VB.NET
  • Javascript & Html Syntax Highlighting #33, JS/HTML
• Unit testing ✨ Test Explorer #80
• AI tooling Copilot Integration #78
• Editor color theme Allow users to fully customize the editor theme #74

Since you have developed the C# support first, it is time to perform refactoring against some good examples of other IDE products and end up with a set of standard API surfaces.

I strongly suggest that some designs follow Visual Studio (LSP, unit test, color theme file format) first, so likely extension authors find similarity and might easily port their VS extensions over. #99 shows that some extensions might not even need a single line of change.

Once we finish VS for Windows extensibility API, we might move on to support some VS Code extensions (very simple language extensions of course, as complex ones require TS/VS Code API which SharpIDE won't support).

[Kysawier]

It would be awesome if there was smt like user configuration/extensibility platform inspired by neovim. In neovim you have an api that allows users to configure their whole config using lua. It's great for extensibility, follow configuration as a code and can be structured as dev wants, additionaly integrations with outside programs/plugins/custom user workflows and scripts is done at the programing language level, glued into nvim apis under the hood.
It would also allow to maintain core as cleanly as you want, focusing on internal logic and api exposure while outside integrations like DAPs, LSPs, Plugins would connect to the api and use underlying infrastructure (or extend primitives if smt isn't yet implemented and plugin author would like to create).
The configuration itself can be easily versioned bcs it's just bunch of files.
I belive that doing a messy vs code style JSON config would be terrible for devs that may want more control. It usually results in a one big unreadable json file with undocumented flags and terrible DX.

[lextm]

@Kysawier History tells a much less romantic story about “maximum flexibility.”

Projects like Eclipse and Atom gave extension authors a huge amount of control, but that also came with real costs: loss of product control, uneven quality, performance problems, and eventually decline. The major IDE families that still dominate today (Visual Studio, VS Code, and IntelliJ) all expose a more limited and deliberate set of extensibility points, whether people like that or not.

Neovim is different in scale, but it still shows the same trade-off in principle. Its flexibility is impressive, yet once you move into plugin-heavy, LSP-heavy setups, the complexity and instability risks are very real. That is exactly why I don’t see “maximum extensibility” as an automatic design win. It remains a minor project with limited field testing, and it already has quite a few performance issues reported related to extensions.

In fact, VS Code was started by Erich Gamma and other longtime Eclipse contributors, so many of its early design choices were shaped by lessons learned from Eclipse’s mistakes. Atom also pushed flexibility further, but its instability and eventual loss to VS Code were hardly surprising.

So I would actually hope SharpIDE focuses on a minimal and stable API surface from the beginning, especially after 1.0. That gives the extension ecosystem something reliable to build on, instead of chasing unlimited extensibility and paying the price later.

[Kysawier]

Neovim is different in scale, but it still shows the same trade-off in principle. Its flexibility is impressive, yet once you move into plugin-heavy, LSP-heavy setups, the complexity and instability risks are very real.

If you have concrete examples in mind, feel free to name them, because “very real” is doing quite a lot of work there unless we are talking about something specific. And context matters here: a problem in Neovim itself, a problem in a plugin, and a problem in an LSP server are not automatically the same argument.

It remains a minor project with limited field testing, and it already has quite a few performance issues reported related to extensions.

Calling Neovim a “minor project with limited field testing” feels overstated. The vi lineage is one of the most battle-tested editor families around, and Neovim itself is not exactly some tiny, unexercised side project.

So I would actually hope SharpIDE focuses on a minimal and stable API surface from the beginning, especially after 1.0. That gives the extension ecosystem something reliable to build on, instead of chasing unlimited extensibility and paying the price later.

What I proposed was not “maximum extensibility” in the Eclipse/Atom sense. It was a fairly normal baseline:

• a proper config directory where users can keep their config files and plugins
• package installation that is not artificially locked down and is accessible through the SDK
• config and API surfaces designed for humans, instead of forcing everything into commentless JSON
• optionally, additional plugin entry points and some packaging support if there is an actual need for it

That is not some grand vision of unlimited extensibility. Most of that plumbing has to exist anyway.

Additionally a plugin SDK will almost certainly need to support config changes anyway — keymaps are the obvious example, since a keybinding plugin has to modify keybindings somehow.

So what I am saying is to focus on making that SDK/API a good interface from the start. That is much easier to maintain than shoving every plugin setting and every system setting into a flat, commentless JSON blob where distinguishing between them is annoying and searching or editing them outside the GUI is miserable.

In fact, VS Code was started by Erich Gamma and other longtime Eclipse contributors, so many of its early design choices were shaped by lessons learned from Eclipse’s mistakes. Atom also pushed flexibility further, but its instability and eventual loss to VS Code were hardly surprising.

Sure, but this is not a post defending Neovim, and it is not a request to recreate Eclipse-era plugin chaos. I am talking about avoiding unnecessary restrictions around config, packaging, and user-level extensibility.

Btw the vi family predates both VS Code and Atom by quite a lot.

[lextm]

@Kysawier If you want to argue for a Neovim-style config model, open a separate issue. Don’t hijack this Epic for your scope.

I disagree with your premise anyway. Tight restrictions on config and packaging are exactly how a project keeps control and stability over time. VS Code’s system is hardly some unusable “flat, commentless JSON blob”, that sounds more rhetorical than real.

And the broader vi lineage is not the point here. Neovim is its own fork with its own plugin/config model, and that model absolutely carries practical instability and performance costs. I don't need to iterate every Neovim bug reports to prove anything.

So yes, I’d much rather SharpIDE keep a small, deliberate, and constrained API/config surface, especially after 1.0. Ultimately, it’s up to @MattParkerDev as the maintainer to decide the direction based on his own priorities.