Summary
Add an early experimental/beta plugin system to ambxst shell, allowing third-party developers to write their own plugins.
Motivation
A plugin system would open ambxst up to community contributions and let users extend functionality without forking or patching the core. This lowers the barrier for third-party devs and helps the project grow an ecosystem.
Proposed approach
Expose a plugin API through an embedded scripting language such as Lua, so plugins can be written and loaded without recompiling the shell.
Add a dedicated Plugins management tab in ambxst settings for installing, enabling/disabling, and configuring plugins.
Suggested priority
I know a plugin system is already on the roadmap. My suggestion is to prioritize stabilizing the core of ambxst shell first, then build out the plugin system on top of a solid foundation. Shipping it as experimental/beta initially would let us gather feedback without committing to a frozen API too early.
Summary
Add an early experimental/beta plugin system to ambxst shell, allowing third-party developers to write their own plugins.
Motivation
A plugin system would open ambxst up to community contributions and let users extend functionality without forking or patching the core. This lowers the barrier for third-party devs and helps the project grow an ecosystem.
Proposed approach
Expose a plugin API through an embedded scripting language such as Lua, so plugins can be written and loaded without recompiling the shell.
Add a dedicated Plugins management tab in ambxst settings for installing, enabling/disabling, and configuring plugins.
Suggested priority
I know a plugin system is already on the roadmap. My suggestion is to prioritize stabilizing the core of ambxst shell first, then build out the plugin system on top of a solid foundation. Shipping it as experimental/beta initially would let us gather feedback without committing to a frozen API too early.