config system prototype

[pascalkuthe]

not anywhere near ready to merge. The general system is mostly complete.
What is missing is porting the entire editor to use the new config system and to add an adapter for the legacy serde config.

I already ported the language server configuration in 27b8257 which should help showoff how this works out in practice.

Rough todo list:

• move helix_core::config to dedicated helix_config crate (feels more appropriate as the codebase has grown a lot
• finis of serde_json::Value to helx_config::Value conversion (going though serde is likely unessesairily complicated implementing from directly should work)
• create definitions for all config options
• add compatibility layer with old serde config
• migrate config loading
• migrate access to config in codebase
• reimplement config based commands (:set :get :toggle) with the new config system

[dead10ck]

Is avoiding an allocation for every config item the only reason we're doing this? Has there been a known performance bottleneck on config memory access?

Trying to understand where this is coming from. This is much harder to understand than just boxing everything, and I was not under the impression that config was in a hot path.

[pascalkuthe]

I actually do kind of think its pretty hot. We read config fields on every single frame for a large amount of config options (at least a hundred) sometimes multiple times. It also reduces memory consumption quite a bit which is more relevant if each config option is set as default, by the user per languages and potentially on the document (so in total up to 4 times). Really this sort of thing ought to be built into rust. There are some efforts around that.

You don't really need to be aware of how this work tough just treat like Box<dyn Any> when reading the rest of the code its really just optimizing access

[dead10ck]

Ah that's true, I didn't consider they are read in the rendering hot loop, good point 👍