helix
helix copied to clipboard
helix-editor
tracking issue: Switch to a scheme based config
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.
- #1513, #1498 and https://github.com/helix-editor/helix/issues/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 #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
- https://github.com/helix-editor/helix/issues/6896 and #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 (#8853 / #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 (#8675)
- [ ] implement ergonomic declarative config in scheme, design discussion in https://github.com/helix-editor/helix/discussions/10441
- [ ] remove toml compatibility layer
I just also want to add to this: Since a lot of Users are Nix users, it'd be a shame to see the nice declarative approach of nix to be gone (not sure if this has been thought of yet) But a nice abstraction layer as it is currently in the flake definition seems to be a very important option (imo)
the nix config can generate a scheme config file. This likely won't cover the full customizability of a scriptable config but it wouldn't be much worse than what we have today. It's not practical to support nix as a first class configuration/scipting language since its not made for that and we can't tie helix to a specific package manager.
This likely won't cover the full customizability of a scriptable config but it wouldn't be much worse than what we have today.
That's basically all I asked for. As a first class citizen it was never in my mind but I am happy as it currently is. :)
Just commenting here as #5046 was closed: I think that it is still a good idea to have some form of direct key-to-key remapping in addition to being able to configure all the keybindings. Sure, proper schemes for remappings of common layouts like Dvorak, AZERY, and QWERTZ will probably be added, but less-common layouts like Bépo might be missed, and I think it's still generally a good feature to have.
To me, the most natural way to use keybindings on a different keyboard layout is… to just use them, irrelevant of what the underlying keys are. Sure, the mnemonics will be messed up, but it's better than shuffling them around to the point where your fingers get tied up. Insertion mode is a separate mode entirely so it doesn't need to worry about those bindings; you can just use the native symbols from the layout.
I don't intend to continue the long discussion that was there already on this here (that would sidetrack the issue). I will mark further comments regarding this as off topic.
But no we will not add this to core. One of the motivations for adding scheme based configs is that we don't have to continuously bloat core with new features and instead offer a more flexible config that will users to add what they need themselves.
Particularly the scheme config should be flexible enough that you can easily implement almost exactly the same thing as https://github.com/helix-editor/helix/pull/5046 in your config/as a plugin. Essentially you would be iterating the current keymap, doing a replacement from one "layout" to another and build a new keymap with the mapped bindings.
Oh, I really should have read more into what exactly this was proposing better. That seems perfectly reasonable then; as long as this is easily doable with the new system, I have no complaints.
I'm curious, how easy is it to (de)serialise scheme compared to toml?
Its not a dataformat it's a programming language so there is not deserialization. You execute code in an interpreter and we habe an API to set config options
...and lisps are known for being able to double as both dataformat and proglang.
I'm looking forward to this.
This issue is not meant to discuss the choice of scheme, please keep such discussion out of this issue.
Where is such discussion intended to occur? I'm a little lost on what the benefits of switching from TOML to Scheme would be. Is there additional context I'm missing?
This issue is not meant to discuss the choice of scheme, please keep such discussion out of this issue.
Where is such discussion intended to occur? I'm a little lost on what the benefits of switching from TOML to Scheme would be. Is there additional context I'm missing?
Personally I think using scheme for the configuration would allow for much more expressive / powerful configurations. For example you can have real control flow, macros, etc instead of purely declarative TOML. Also, it has the potential to be much more consistent and elegant with the upcoming scheme-based plugin system.
You asked for related issues, MikeDavis mentioned needing a programmable config for this one https://github.com/helix-editor/helix/issues/2882
I understand the motivation behind adding programmatic configuration, but I'm curious: is it truly necessary to drop TOML as a config format? I'm not here to argue against adding scheme support, though I really don't want to have to learn it myself. And there are some valid reasons to avoid executable config files.
I understand the motivation behind adding programmatic configuration, but I'm curious: is it truly necessary to drop TOML as a config format? I'm not here to argue against adding scheme support, though I really don't want to have to learn it myself. And there are some valid reasons to avoid executable config files.
Agree. There are some valid reasons to avoid executable config files!
I think many users (just like me) just want simple configs as toml format. If we want to add some new kind of scheme, we can still keep toml compatible. I like toml and helix's simplicity and DO NOT want helix to be complex and giant.
I understand the motivation behind adding programmatic configuration, but I'm curious: is it truly necessary to drop TOML as a config format? I'm not here to argue against adding scheme support, though I really don't want to have to learn it myself. And there are some valid reasons to avoid executable config files.
Maybe it would be good enough to provide a simple Scheme function that loads config from a toml file?
