-
-
Notifications
You must be signed in to change notification settings - Fork 796
feat(config): add KDL v2 support #3908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
I’ll… figure out what’s going on with the tests soon 😅 might be a fallback issue. |
Hey! So - I'm starting to take a look at this. Right now on this branch, Zellij doesn't start. We get a I think an easier example to iterate over would be this test: https://github.com/zellij-org/zellij/blob/main/zellij-server/src/tab/unit/tab_integration_tests.rs#L6567 - in which we're failing to serialize one of these: https://github.com/zellij-org/zellij/blob/main/zellij-server/src/tab/unit/tab_integration_tests.rs#L6574-L6588 and https://github.com/zellij-org/zellij/blob/main/zellij-server/src/tab/unit/tab_integration_tests.rs#L6592-L6608 I'm not too sure why every now and then we get a failure for the 1st and at other times we get a failure for the second. I can try to take a deeper look if something doesn't jump out. I'd recommend skipping our build system and running it directly inside the |
Any chance at least partial v2 support may be added? It is particularly mocking to see tons of syntax errors, when editing those KDL files with an up-to-date language server and then getting errors like this from Zellij.
While the referenced documentation specifically says, that plain text booleans are not allowed, plus other notes regarding booleans' special treatment. Would be a huge & immediate DX improvement, if those booleans would be fixed. |
While I would definitely want to see KDL v2.0 support in Zellij, the migration is not trivial (nothing to do with KDL and everything to do with infrastructure changes in a large code base being time consuming and difficult). Add to that the admin work that would have to go with it (communicating this to users, migration paths, updating documentation/screencasts/tutorials, etc.) and this becomes a large project with limited impact on the quality of life of users. Zellij is underfunded and our development resources are stretched thin. I prioritize what I think is right. I absolutely love KDL and am dying to see V2.0 in Zellij, but I just can't afford to spend the time on it presently. |
I've been kinda crispy and busy with a new job and other life stuff, but if there's anything from the list of things blocking this that you think me or the community can pick up to lighten your load, @imsnif, just lmk. I imagine at least some of those things you would want to end up doing, yourself. |
For sure. I think if you or someone from the community would like to make a PR that can parse v2 files as easily as it can v1, I can do the rest. Not for this upcoming version in crosses fingers a few weeks time, but I can make the time for next one. |
isn't that basically what this PR is? |
It is, yes! But I think there's still a bit of work to be done here. |
absolutely! Just making sure we're on the right track. And if anyone else wants to help me with this PR, I could use the help, too :) |
Fixes: #3891
Starting this off as a draft, so we can discuss the changes and see what needs adjusting. I had to update dependencies a bit in order to resolve some cargo resolution conflicts, and with that came a bump in MSRV, as well as the removal of the deprecated
backtrace
feature forinsta
.This uses kdl-rs' built-in "v1-fallback" system: It will first try to parse a KDL document as if it were v2. If that fails, it will try again with the legacy v1 parser (which is identical to the one Zellij is currently using, so v1 docs will parse the same). If both fail, kdl-rs will try to apply some heuristics to figure out which parser's errors to display, and if the heuristics fail, default to v2 errors. Note: It is completely safe for well-formed v1 or v2 documents to be parsed with either parser. If a document just so happens to parse successfully under both parsers, the returned data will be identical.
Since the new KDL v2 parser also supports multiple diagnostics, I took the liberty of restructuring the KdlError type such that it would support that, too, and integrated it with the new error types from kdl-rs. This change also means that Zellij will be able to return One Big Err with a bunch of diagnostics in it, instead of erroring and exiting on the first failure (DeserializationErrors will already do this--but you will now be able to append errors either to that, or to the post-deserialization semantic checks).