ellie
May 8, 2024, 5:45pm
1
I am more than happy to create a PR, but I think it makes sense to have the “new” settings in place. Otherwise the current config file is getting more and more convoluted. I also find it a bit problematic that some settings do not belong to a table. I believe tables like [client], [main], [server], [history], … would be beneficial.
I can also help with the new settings, but no decisions have been made regarding format and architecture.
If the decision re format has been made, I can create a p…
More tables would be sensible, and new features should be properly fit into tables (as all so far have been)
I think there’s a midground we can achieve more easily/quickly where we just shuffle the existing settings around a bit, and leave the existing options where they are. Just remove them from the default config, and mark them as deprecated in the docs.
It may also be nice to mirror the crate structure with settings, as this is already grouped in a way that makes more sense. It would also reduce the dependencies a bit.
Longer term, I think KDL would work nicely.
Related:
atuinsh:kolektiv/styles ← kolektiv:kolektiv/styles
opened 12:08AM - 29 Feb 24 UTC
WIP
Continuing previous pull request...
The Settings refactor is probably … a little better than the previous growing flat structure, but it could do with a proper overhaul at some point I think. Still, it should do for now. This should be enough to try and test various configs - in theory it shouldn't have changed the format required, but that's not tested...
- [x] Settings Refactor
- [ ] Styles completed
## Checks
- [ ] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
- [ ] I have checked that there are no existing pull requests for the same thing
atuinsh:main ← arcuru:configv2
opened 04:59PM - 27 Feb 24 UTC
This is intended to be more of an example/discussion than a PR that should be me… rged. This PR format just may be a bit easier to make comments on, but we can move discussion somewhere else.
The config file is getting pretty unwieldy. Ellie has been pushing towards adding some more structure to it, but I think we need to re-organize some of the existing options.
There are a lot of contributions lately that are adding new options, I think this is a good time to make sure there is a cohesive plan to the options layout.
We have several logical groups of options that can pretty cleanly be grouped together. The most important is I think the keybindings. We can move the `--disable-up-arrow` option into the config file, more cleanly customize the filter/search/workspace modes, and have a switch for #798 if that gets implemented.
@ellie, feel free to close if you already had your own goals here :)
## Checks
- [x] I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
- [x] I have checked that there are no existing pull requests for the same thing
1 Like
ellie:
I think there’s a midground we can achieve more easily/quickly where we just shuffle the existing settings around a bit, and leave the existing options where they are. Just remove them from the default config, and mark them as deprecated in the docs.
I think that makes sense. Maybe a mapping document (markdown table) would be a good start. After having it confirmed, the code changes should be easier to manage. What do you think? I can give the mapping table a try.
I have never seen or used an application that uses KDL, so I have to look into it. What I can see from the docs, it’s not as legible as TOML or YAML.
ellie
May 9, 2024, 1:22pm
3
A mapping doc sounds great!
1 Like