Support for WASM plugins

sublimehq / sublime_text

Issue tracker for Sublime Text

https://www.sublimetext.com

801 stars 35 forks source link

Support for WASM plugins #6365

Open lamg opened 2 months ago

lamg commented 2 months ago

Problem description

I want to develop Sublime Text plugins, and already feel comfortable platforms and languages like .NET, F# and OCaml. This is not the case with Python, which would require an investment of time which I wouldn't reuse.

Preferred solution

Support for plugins compiled to WASM. Maybe extism could be helpful.

Alternatives

Support for plugins developed with .NET

Additional Information

No response

jfcherng commented 2 months ago

Unless ST team wants to maintain two API sets, one for Python and one for WASM.

I think it makes more sense that to write a plugin as a wrapper which calls functions in WASM. Using https://pypi.org/project/wasmtime/ probably. Someone made a simple tutorial for it on https://dev.to/ajeetraina/using-webassembly-with-python-o61 but I don't have a precompiled .wasm to test.

I tested gcd.wat from https://docs.wasmtime.dev/lang-python.html#getting-started-and-simple-example with wasmtime in ST's py38 plugin host and it works.

>>> from wasmtime import Store, Module, Instance

store = Store()
module = Module.from_file(store.engine, R"C:\Users\jfcherng\Desktop\gcd.wat")
instance = Instance(store, module, [])
gcd = instance.exports(store)['gcd']
>>> 
>>> 
>>> print("gcd(27, 6) = %d" % gcd(store, 27, 6))
gcd(27, 6) = 3

deathaxe commented 2 months ago

Actually API bindings for each target language were required, which is way more work to do, I guess. WASM is just a sort of byte code running in a VM.

Also the wasmtime approach required creating API bindings for those languages to support and somehow use python plugin_host as proxy.

lamg commented 2 months ago

In summary:

Pros:

Write plugins in any language that can be compiled to WASM

Cons:

Sublime team has to maintain two APIs
WASM doesn't define a call convention

Addressing the cons:

Sublime team might want to maintain a WASM API if that means an explosion in plugin development. A more rich ecosystem is the reason people prefer VSCode.
I don't know much about WASM, but Sublime team could define a calling convention, and/or rely on extism, which I think provides it. People interested in developing Sublime plugins could do their job and provide more idiomatic interfaces for their languages, on top of the basic one.