Showing content from https://github.com/helix-editor/helix/discussions/3806 below:
Plugin system · helix-editor/helix · Discussion #3806 · GitHub
I'm Just ordinary user chiming in.
From the description from on https://github.com/bytecodealliance/cargo-component , the components model came up because they needed to wrap WebAssembly modules. It seems like there is some need to make a wit-bindgen like tool for the components model, so some solution should arrive soon.
Herein, I try collect in one place, summary of sub-discussions for quick reference, with links included inline to the actual sub-discussions.
Plugin language options
- wasm <- CBenoit WebAssembly plugins system #122
- variants:
- pro: most languages with wasm target will compile or JIT-compile to it. (grain , assemblyscript)
- pro: possibility of code-sharing with other editors/ides and porting of their already developed plugins
- pro; wasm byte code for the wasm virtual machine is distributable across any architecture
- pro: sandboxing
- pro: bytecode is almost as fast as native, but much faster than other interpretted languages. The blazing speed of wasm runtime, can make the speed difference of feature implementation between in-core and via-plugin imperceptible.
- con: cannot use native-binary system-local libraries
- con: API/ABI not yet stable, development library/tools not yet available
- rust-itself <- pascalkuthe #3806 comment 3644259
- con: compilation required which is impedes rapid-script-style development (not a scripting language)
- con: either plugins will need to be distributed as binaries for each architecture, or user will need entire rust compiling toolchain
- con: some super secure trusted computing environments may not allow users to download/run/link non-approved binaries, even in their own userspace
- plus all of what pascalkuthe in prev-ans said above
- Interpreted rust <- hgkamath #3806 comment
- implementation efforts towards rust-REPL include: evcxr, miri, papyrus, IRust, rusti, replit
- con: no mature implementation, a dependable rust JIT/REPL does not exist as of today
- con: rust is not known for fast compilation. So, startup and execution performance will also be slow
- pro: can be a stepping stool towards compiled-rust-based-plugins
- lua, web/luajit web<- JHoanker #2949 comment 1191709989
- pro: popular, simple easy to learn language
- pro: fast
- implementation lang: C
- con: not many libraries
- con: not suited for large codebase linking
- con: problems seen from neovide's experience.
- possible to support lisp via fennel-lisp, which is written in lua and compile lisp to lua
- lisp family
- janet, web <- glyh #2949 comment 1186221704
- implementation lang: C
- pro: has rust binding janet-rs
- con: rare language
- con: too new, seldom used
- rhai, web <- stappersg #3806 comment 3629810
- pro: implementation lang: rust
- feature: customizable language
- con: rare language
- con: too new, seldom used
- con: slow AST language
- con: archseer above said it has bus of size 1 ( developed by 1 person)
- rune, web
- pro: implementation lang: rust
- con: rare language
- con: too new, seldom used
- gluon, web
- pro: implementation lang: rust
- con: rare language
- con: too new, seldom used
- javascript <- SoraTenshi #3806 comment 3634736
- pro: very popular, ubiquitous language
- pro: javascript engines have evolved to become very fast, within reasonable order of native.
- con: javascript is a messily evolved language that makes it too easy to write equally messy code with bugs
- con: huge language to embed, increases compile-time and startup-time
- runtimes
- python
- via
- pro: very popular language with huge number of modules
- con: slow
- con: making sure compiled-in crate interops with system installed python libraries.
- con: likely to require multiple virtualenv management for each plugin, which takes up user space disk-usage.
- con: some pip installs pull in binaries or need local pre-compilation
- con: huge language to embed, increases compile-time and startup-time
- no plugin system/all features in core <- robertkleene #3806 comment 4070879
- pro: all most features usually needed by developers will work right out of the box
- pro: core-devs relieved of need to maintain plugin system, plugin-api and its versioning
- con: features will need to be maintained in lockstep with helix-core, cannot develop at their own pace. as no gradually evolving plugin-api
- con: no parallel/competing implementations of features
- con: raises barrier to entry for a new potential feature to make it to core
- con: there can be many unanticipated special requirements.
- con: user can only customize what existing features allow to customize
- con: can lose ordinary-users with specialized niche-needs fulfill-able via plugins.
- con: can also lose users, who want the contingency option to want a plugin if an unanticipated need ever arises.
- con: can lose power-users who want plugin-grade power and control. Such users have potential to become future contributors.
- con: base install may become bloated, may also increase startup-time
- exposed json api <- ksandvik #3806 comment 4081149
- pro: any feature developer can use any tool they want
- pro: would be suited for nushell type json processing
- Essentially dev energy will move from embedding a scripting language to development and maintenance of a json-api.
- con: can be very slow, as this will require starting external executables, json interconversion. So not suitable for reactive interaction
- con: may require external programs/processes to keep running and maintain state
- con: shell scripting is not the best way to write large programs
- con: plugins that rely on shell or external tools may not be always be cross-platform and are certain to bring in platform dependencies. This case is like the polar opposite of sandboxing.
- Ref/Links
The case for plugin-provided-feature
- Not possible to anticipate all special requirements.
- Never possible to claim all needs of all users are met. Plugin candidate features are infinite. A user, due to repetitive editing work, will feel the need to exchange/manipulate text from an out-of-process/network resource (ex website/etc) that could have been done faster with a plugin.
- A plugin is preferable when the feature depends on the existence of the web-resource such as a 3rd party provider of some service.
- Plugins allow for easier private changes. One cannot assume, all created plugins will be shared. One may create a for self-only/organization only plugin in cases where it makes no sense to share, like for a private resource. Without plugins facility, user has to make direct changes to core-code, which implies user is forced to recompile whole editor.
- Another class of plugins are for UI-customization, for which preferences are subjective.
- Plugins have a low barrier to entry for a user to contribute.
- Languages chosen for plugin are high-level, have REPL, suitable for prototyping, and are live code-able. They are hence relatively easier to learn and code, as compared to low level system programming languages.
- Attracts a special-feature-requiring-new-user, if plugin/feature desired by the user exists
- Attracts and retains power-users and users who want customizability and control via plugins
- Plugins decouple plugin development from core-development. If too many features are pushed into core, it increases the maintenance work on core-developer. If the core-feature developer fades away, increases work-load on present maintainers. Larger software has larger cognitive load on the developer, and can cause maintainer-fatigue. On the other hand, if a plugin is abandoned, it may get adopted and re-developed. It may be retired/quietly-dropped with less impact to core. Users may also switch to an alternative competing plugin.
- Plugins, by making life easy for core maintainers, allows for project longevity.
- Plugin installs are separate and self-contained, and hence bring no platform dependencies
- Plugins allow for parallel/competing implementations of features. The competition keeps plugin developers on their toes. Plugin competition, keeps alternative ideas and ways of doing things alive for those who need them, instead of forcing only one-way of doing things.
- A plugin-api forces a interface, which decouples the plugin-code from all of the core-code. The advantage of this is that changes within core and changes within the plugin are less likely to cause unintentional breaks as long as they conform to the api. This is sound, as opposed to monolithic development, where any call/access can be made to anywhere, and one has to work out if a change affects any callees/accessees. A integrated feature would require a proposals, reviews and more steps to be accepted. A plugin, being more independent, can be developed faster and upgraded.
- Script style development is faster to share and contribute. It also allows a user to make a custom tweak in the inner workings if necessary,
- Plugins can be downloaded and installed on need, avoiding bloat.
- Plugins, upon starting editor, can be minimally-initialized and lazily-loaded on need, saving startup-time.
The case for in-core-feature
- Core features work right out of the box
- A candidate feature for in-core feature is very likely one that is a must-have. Over the past three decades, there is some agreement that some editor features are must-haves, and that they might as well be integrated. ex vcs, ruler, file-explorer, file/buffer-diff, terminal-buffer, etc.
- A feature is suitable to be in-core when there aren't many alternate ways of implementing the feature.
- Possible to make-build by static-linking or dynamic-linking to any platform or bundled library in blazing fast native code. Expectedly libraries already exists for almost any feature one might ask for. pro: fast. con: bloats the core, creates build and install dependencies
- Speed: A core feature implemented in Rust will be blazing fast and will beat any plugin implementation. However, the blazing speed of wasm runtime for plugins, can make this difference negligible.
List of candidate plugins
List of conventional-plugin-features gone in-core
Desirable characteristics of a plugin system
- gozzarda #3806 comment 4270848
- even if helix supports dynamically typed plugin languages, desirable to have a statically typed interface
- asynchronous wherever possible
- sandboxing, plugin memory separation,
- a way to marshall calls and return values
- xJonathanLEI #3806 comment 4270883
- ability to do permissioning on sandboxed plugin
- kirawi #806 comment 3629638
- Interpreted
- Reliable
- Popular
- Small footprint
- blazing fast byte code virtual machine
- any language should be transpilable to the byte code
- rust implementation
Projects that are noteworthy for their plugin system implementation
- extism, web: <- yogeshdhamia #3806 comment 4285371
- A universal plugin system
- wasm based
- implementation lang: rust
- graph-node, web: <- xJonathanLEI #3806 comment 3988059
- has a wasm runtime
- target language assembly script
- implementation lang: rust
- Zellij, web:
- lapce , web: <- archseer #3806 comment 4713353
- Blender, web: <- Z2Up1UwcaYOyZq #3806 comment 4343127
- ships almost-all plugins at once with main installer
- of them, some are enabled by default, whilst others are disabled by default
- clear distinction between official plugins and non-official 3rd-party plugins
- seems to be many 3rd-party add-on/script markets.
- Emacs <- jgarvin #3806 comment 4079704
- Emacs has plugins to avoid/manage RSI
- Emacs has pushed what plugins can do the most
- VScode, web:
- VScode compatibility may be desirable
- In the beginning, extensions were written to restrictive contribution points. Advanced contribution points came later <- spion #3806 comment 4071144
- More and more developer tool companies will release extensions for vscode, but this sentiment can only go so far <- tubba #3806 comment 4491845
- nushell, web <- getreu #3806 comment 5314935
- Vplugin : <- tukannoidd #3806 comment 5703649
- pro: Rust based, low-level block, is its own plugin-API with format,
- con: still in development, other language bindings not yet there.
Other discussions
so... where we at?
Q1) Is choosing a plugin language now, just a temporary stop gap for small simple plugins until wasm matures, just to buy time for an eventual later migration?
Q2) neovim has both a lua and vimscript engine. Would helix be able to have multiple simultaneous plugin language engines, perhaps aiding transition if the afore-said stop-gap were to be retired?
Q3) Would the plugin api be designed to be so that it mimics vscode so that as many plugins from vscode eco-system be easily ported?
Q4) If lapce (a gui code-editor like vscode) is going with wasm, wouldn't that also allow easy script sharing and porting with helix (and also kakoune if it gets a wasm plugin engine)?
Q5) Would plugin system allow for dynamic load/unload or one time load on startup?
notes
- kakoune is a modal editor implemented in C++, has minimal scripting with kakscript and also in plugin-engine selection-limbo with no official plugin system.
Helix holds much promise. thx to the developers
P.S.
- This post only serves to collect links to sub-discussions that have been made elsewhere. Credit of content goes to the knowledgeable comment-posters. Any limitation/bias/omission in this post is my fault. Any new information pointed-to or contained-within is thanks to contributors. So, please don't post comment to this post, unless you are alerting me to a needed correction.
- Make your posts/comments by replying to sub-discussion/subtopic specific comments where the sub-discussions/subtopics are made. The links to the posts/comments can be found above. As the discussion is now closed, do exercise restraint before posting a new thought. Please search/do Ctrl-F to see if the thought is already posted.
- kirawi has called for end of discussion and need for implementation. Any general closing comments to the discussion are best made to kirawi's post of 20221222 kirawi #3806 comment 4404346
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4