Move All Zellij Configuration to KDL

[TheLostLambda]

KDL is pretty nice!

The plan it so use it instead of YAML for configuration and layouts (which will also be unified)

This change will involve writing a bit of parsing code, but let's get the format nailed down first!

Here is a demo of keybind configuration with syntax highlighting!

[a-kenji]

This looks good already. Could you add the themes as well? So we can have some idea on how they would look?

[TheLostLambda]

Could you add the themes as well? So we can have some idea on how they would look?

@a-kenji Where do these normally live? Should they be a subsection of the config file? Sorry, I've also not played around much with the themes before 😅

[TheLostLambda]

@a-kenji Maybe like this? This is just in the themes folder though – I don't know if it belongs in the config yet!

[TheLostLambda]

I've also added some layout KDL!

[a-kenji]

@TheLostLambda,

Yes like that! The theme would get dropped just like that in the config file.
Important would be that it would also work like that.

tokyo-night-light {
    fg 52 
    bg 213 
    gray 150 
    black 15
    red 140
    yellow 143
    blue 52
    magenta 90 
    cyan 15 
    white 52 
    orange 150 
  }

[a-kenji]

I've also added some layout KDL!

Awesome, keep in mind that you can also set options in the layout!
(And keybindings, but they are one of the non-functional ones that still need work - which I talked to you about offline.)

[TheLostLambda]

Yes like that! The theme would get dropped just like that in the config file. Important would be that it would also work like that.

tokyo-night-light {
    fg 52 
    bg 213 
    gray 150 
    black 15
    red 140
    yellow 143
    blue 52
    magenta 90 
    cyan 15 
    white 52 
    orange 150 
  }

Awesome! This should already parse fine, but what does this mean in terms of actual colors? It's some sort of indexed color space?

Awesome, keep in mind that you can also set options in the layout!
(And keybindings, but they are one of the non-functional ones that still need work - which I talked to you about offline.)

Awesome! Should be pretty easy as all of the top-level sections (modes, template, options, tabs, etc) are unique!

[a-kenji]

Awesome! This should already parse fine, but what does this mean in terms of actual colors? It's some sort of indexed color space?

It is the color space our default theme uses, to be compatible with every terminal, since not everyone supports truecolor. But if it parses, then it's not problem - since we already handle it.

https://zellij.dev/documentation/themes.html

Awesome! Should be pretty easy as all of the top-level sections (modes, template, options, tabs, etc) are unique!

👍

[TheLostLambda]

As an implementation question, would people find it cleaner to keep the current FromYaml and also a "true" version of structs and use knuffle, or should we just implement things ourselves with kdl-rs and get rid of the confusing struct duplication?

I'm thinking about things like shared-except in the keybinding process – they need custom logic to be merged into the other modes.

[imsnif]

As an implementation question, would people find it cleaner to keep the current FromYaml and also a "true" version of structs and use knuffle, or should we just implement things ourselves with kdl-rs and get rid of the confusing struct duplication?

I'm thinking about things like shared-except in the keybinding process – they need custom logic to be merged into the other modes.

My instinct tells me that this seems like conversion implementation and thus we'd better make it explicit rather than relying on an intermediate struct - but @a-kenji has a lot more context so maybe he thinks differently.

[TheLostLambda]

I'd personally prefer the same, as it would help clean up a lot of redundant structs, but also keen to hear what @a-kenji thinks!

[a-kenji]

As an implementation question, would people find it cleaner to keep the current FromYaml and also a "true" version of structs and use knuffle, or should we just implement things ourselves with kdl-rs and get rid of the confusing struct duplication?

I'm thinking about things like shared-except in the keybinding process – they need custom logic to be merged into the other modes.

If we still have the same functionality and it doesn't get more complicated I don't care either.

I would like to keep the ability to just add an option and it being added to the options subcommand, the configuration file and the layout file as it is right now. What kind of structs we use doesn't really matter imo.

[TheLostLambda]

An update for those following this: I've started chopping out the FromYaml code, but have come to the horrifying realization that only some of the FromYaml structs are intermediate serde types...

I wanted to chop out all of that then rebuild to parse the non FromYaml structs, but 800 lines of deletion and more than an hour later has me no closer to something that can compile... I'm going to revert all of that destruction, then build the new parser on a new branch from a clean repository – I'll link that here once I've done that!

[TheLostLambda]

For anyone interested in my future KDL battles: https://github.com/zellij-org/zellij/tree/kdl-burnsite

[har7an]

Resolved in #1759