C++ based add-ons support (revisited)

ghost commented 4 years ago

Problem description

Currently, the only way to integrate support for more features is to write glue code in Python. There are some of us who aren't adept enough at Python to write efficient glue code and getting contract programmers for a narrow domain like this is quite difficult.

Preferred solution

Expose core APIs which can be tapped into using C++ (since Sublime itself is written in C++) or any other language the user feels most comfortable using and provide documentation of your native development environment for supported platforms so that module/extension writers can use the same to build their own stuff.

Problems solved by this approach

Some extensions which need to display their output as high-performance graphics would be able to better accomplish their goals if allowed to tap into the core to extend the editor towards making it a full-fledged IDE.

Issues that might arise

The open source eco-system of modules would get disrupted as people would build closed source components. But you could think of it as a way to bolster the viability of your own product since people would now have an incentive to build modules which are more commercially viable in their closed source state. Sublime core is anyways closed source and should remain that way.

rwols commented 4 years ago

This seems to be the same issue as https://github.com/sublimehq/sublime_text/issues/3095.

wbond commented 4 years ago

I don't foresee this happening. C++ is so fraught with undefined behavior, crashes are trivial to cause by accident, memory leaks are extremely common. Beyond that, the cross-platform developer story is extremely fragmented, and it would be very hard to get started.

If a programmer is not able to pick up Python and write some glue code, then I tend to think that the C++ results would be relatively poor. C++ is much more difficult to write safe, correct code in. The primary benefit being that C++ tends to be faster and use less memory for the same functionality as Python.

Currently it is possible to write closed-source software using Python. Various companies sell packages by shipping the compiled .pyc files. Adding a more difficult ecosystem for plugins is unlikely to disrupt the Sublime Text plugin ecosystem. Notepad++, which uses C++ only has 102 plugins available (https://github.com/notepad-plus-plus/nppPluginList/blob/master/src/pl.x64.json), where Sublime Text has many more (https://packagecontrol.io/browse/labels - not all are plugins, but many are).

If an attempt to allow non-Python plugins to interact with Sublime Text was undertaken, I would envision it something like this:

A well-defined protocol would be written allowing other processes to send "instructions" to Sublime Text
An authentication/protection layer would need to to be written to ensure invalid/malformed commands were not sent
A declarative or scripting language would need to be made to control the spawning/reaping of "plugin" processes

Effectively we'd need to recreate all of what we get via Python using other approaches, and it would take a lot more work for plugin authors since they would either need to ship an entire language runtime (say JS) or compile and ship platform/arch-specific executables. But we'd really want to have a simple path like the existing Python environment.

Which leads us back to where we are. Currently the Python API can use the plugin_loaded() and plugin_unloaded() handlers to spawn third-party executables using the subprocess module, and relay API calls through to Python using stdin/stdout or any other number of interprocess communication facilities. This solves all of the bullets above, and is available now.

The one thing you mentioned that this wouldn't allow is "high-performance graphics", which I tend to think we wouldn't ever expose low-level capabilities of.

wbond commented 4 years ago

There doesn't appear to be any further discussion, so I am closing.

sublimehq / sublime_text