search

helix-editor / helix

A post-modern modal text editor.
https://helix-editor.com
Mozilla Public License 2.0
33.65k stars 2.5k forks source link

tracking issue: Switch to a scheme based config #10389

Open pascalkuthe opened 6 months ago

pascalkuthe commented 6 months ago

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.

Work items:

SoraTenshi commented 6 months ago

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)

pascalkuthe commented 6 months ago

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.

SoraTenshi commented 6 months ago

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. :)

clarfonthey commented 6 months ago

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.

pascalkuthe commented 6 months ago

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.

clarfonthey commented 6 months ago

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.

AndreiSva commented 6 months ago

I would love this

gyreas commented 6 months ago

I'm curious, how easy is it to (de)serialise scheme compared to toml?

pascalkuthe commented 6 months ago

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

gyreas commented 6 months ago

...and lisps are known for being able to double as both dataformat and proglang.

I'm looking forward to this.

gyreas commented 6 months ago

Btw, there's still a typo in the title

CaesarXInsanium commented 6 months ago

I think it's funny that there's typos here.

omentic commented 6 months ago

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?

AndreiSva commented 6 months ago

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.

omentic commented 6 months ago

Ah, that seems to be the context I'm missing.

poliorcetics commented 6 months ago

You asked for related issues, MikeDavis mentioned needing a programmable config for this one https://github.com/helix-editor/helix/issues/2882

zmc commented 3 months ago

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.

ireina7 commented 3 months ago

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.

alexeymuranov commented 3 months ago

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?