We have settled on a scheme (likely steel see #8675) based plugin system. One of the primary goals of the plugin systems is not just allowing user to write plugins for functionality that isn't suited for integration in core but also to allow a more flexible, scriptable and extensible config that will replace that config.

This issue is not meant to discuss the choice of scheme, please keep such discussion out of this issue.

There are many open issues that we want to address with a scheme based config. We generally don't want to invest more time into significant additions to the toml config so I will be closing these issue in favor of this one To make easier to track I decided to centralize these issues here. Once an initial prototype lands we can split out issues fro undressed features again but right now that we don't even have a prototype that just isn't productive. I tried to give a rough summery of how I hope to address these things but these aren't in depth proposals/fully developed ideas yet. We should expand this list as I am sure there is more, this is just a starting point of the issues I could find.

• Allow composition of configs to avoid duplication #1513, Allow reusing a list of commands for dialogs #1498 and Adding command support for minor modes #5734: allow defining/reusing keymap bindings (both grouping and sequences): Will be automatically handled by making keybindings first class values (that can be stored in variables). This will include the builtin minor modes
• issues like bug: normal mode hardcoded with english layout #133: these would be solved by allowing you to transverse the keymap so you can implement automatic remapping in your config or with a plugin
• Add a way to extend file-types key in languages.toml #6896 and Language configs are not merged between user-wide and project-specific files #3702: keep the current behaviour of overwriting (since its imo the right thing to do) and add a function that automatically merges instead
• any breaking changes we may want to make to the config should be done during the migration as we are breaking users configs anyway

Work items:

• revamp the config system so its flexible enough for a scritable config and not inherently tied to serde/toml anymore (RFC: Revamp Config System #8853 / config system prototype #9318). This will remomve most of the current based toml/serde based system and only leave a compatability layer in place
• add scheme support to helix (Add Steel as an optional plugin system #8675)
• implement ergonomic declarative config in scheme, design discussion in Design discussion: Declarative scheme config #10441
• remove toml compatibility layer