Update settings at runtime

[irevoire]

Hello @pickfire, I was not happy with #798, and I was thinking about your comments, and I thought something was wrong with my first implementation.

Mainly I didn’t like this solution. I feel like matching on a string will be a kind of technical debt. Everytime we’ll update the Config structure we’ll need to remember to update this match statement in a totally random place in the code.

And then, while looking at what kakoune did, if we want something like them we’ll need to store “parts” of the config in multiple place.
For example, we could have our “base config” as we have currently. And then each window and buffer could have its own “incomplete” config.
And then to get the “real” config you would:

1. Take the base config
2. Apply the window config to it (=overwriting every field of the base config that are defined in the window config)
3. Apply the buffer config in the same way

To make this “type-safe” I didn’t find any other solution than creating a “typed fsm” (I don’t know if it’s the term) where a config can either be Complete or Incomplete.

If the config is Complete, when we access one field it returns the expected value as before. If it’s Incomplete it returns an Option.
The code is a little bit raw right now; maybe we could create a macro or something like that.

But before spending too much time on it I would like to hear what you think of this idea. Is it something we want to merge?
It changes a lot of code, but I think it’ll allow us to do some great things later in a type-safe and fast manners!

[pickfire]

I think we don't have to do this, we can just use a default for it in case it isn't there rather than being None.

[pickfire]

I think being able to change all runtime settings is what we want later. But I don't think we need to keep track of whether values is set or not, we can just use the default and when it is set, override it with what the values was set.

[irevoire]

But then if I have a "line-number = none" in my global config and I want to change it back to the default value: "line-number = absolute".
I'll get a config struct with all its field at the default value and I can't detect what changed?

[pickfire]

I'll get a config struct with all its field at the default value and I can't detect what changed?

Why do you want to detect what's changed? Line number none is a value by itself, which is not the default. If user set it to none obviously user wants it being none.

[irevoire]

If the user set it to none obviously user wants it being none.

Yes, my question was not about setting the value to none, this should work without any effort.
My question was: when the user wants to set it back to absolute at runtime, I'm going to end up with a struct where all its fields are at the default value where I can't know what the user wanted to do.

[pickfire]

My question was: when the user wants to set it back to absolute at runtime, I'm going to end up with a struct where all its fields are at the default value where I can't know what the user wanted to do.

I don't think we need to do that, we can just mention the defaults. That's how vim and kakoune did it IIRC, they just mentioned the default and you can set it back to that value yourself, not like set ft=default.

[irevoire]

If you really want that I can do it with the other PR. But from a user perspective, I find it quite bad personally.

If I think “I want to set absolute number” I’m not thinking “I want the default settings back”... I don’t even know what is the default setting usually 😒
I’ll need to remember the default for each setting because if I don’t my modification will just get ignored without any warning or error... Yeah not a fan.

[pickfire]

If I think “I want to set absolute number” I’m not thinking “I want the default settings back”... I don’t even know what is the default setting usually unamused

Regarding this, it should be shown in infobox like what kakoune did, since we can't expect user to remember.

So I guess if we display it in the infobox it solves the issue?

[archseer]

Sorry for the delay, I'm not completely satisfied with the amount of boilerplate code here (and needing to subtype config into complete/incomplete). Trying to think if there's a better way to accomplish this.

I think I agree with @pickfire in that it's not too important to us to track which values are set and which fall back to the defaults. Rather, I'd keep a single config object (like we have now, that merges built-in defaults with the config file), then :set would directly change it at runtime as needed.

If I think “I want to set absolute number” I’m not thinking “I want the default settings back”... I don’t even know what is the default setting usually

Precisely. If I change a value I can always manually change it back.

[irevoire]

Closing in favour of #798