Feature Req: Schema/Linting standard for hyprland config

[DaveWK]

Description

I like the config based approach in Hyprland, but it can be confusing as a newcomer to enumerate and understand all the config options, and there's a potential for the dreaded combination of syntax errors and misconfiguration when trying to figure out how the config works.

It would be nice if I could edit my config in an IDE and it was able to validate my config syntax, ensure the configuration options have valid keys/values, and identify any problems with the "nesting" of objects being at the right height.

I would suggest using an existing open schema standard for validation to allow third-party apps such as IDE's, yaml/toml/whatever config macros, and extensions that generate some of the boilerplate config.

[NotAShelf]

@yavko

[yavko]

I am working on a parser and lsp that should at least help with ide stuff

[RichardFevrier]

Since we can source a file (multi-file configs) into hyprland config, wouldn't the lua file format more appropriate?

[sandhilt]

+1 for lua, most tools use this language for config

[vaxerski]

no

[10b14224cc]

Here is a tree-sitter parser for hyprland config file, to be used with neovim: https://github.com/hyprland-community/hyprparse

[yavko]

Here is a tree-sitter parser for hyprland config file, to be used with neovim: https://github.com/hyprland-community/hyprparse

That's my parser, not the treesitter

[10b14224cc]

Here is a tree-sitter parser for hyprland config file, to be used with neovim: https://github.com/hyprland-community/hyprparse

That is the correct one: https://github.com/luckasRanarison/tree-sitter-hyprlang

[gnull]

There's one more thing: maybe errors and syntax generally can be improved to help newcomers.

1. Currently, the errors users get are really confusing. Like failed parsing a vec2: stof or failed parsing a vec2: no space with no further explanation if you get Vec2 wrong. (I'm guessing that the C++ code is doing some Codeforces-style parsing by hand and moving pointers around there.)

   Also, the Vec2 formats in hyprctl (10 20), in documentation ([10, 20]), and in config (10, 20) are all different.

2. Argument structure is flattened into one list. Like

   bind = $mainMod SHIFT, left, movewindoworgroup, l
   

   while structurally this is more like bind(mainMod SHIFT, left, movewindowgroup(l)). Would be nice to have syntax that can reflect this structure and, if user gets it wrong, print an informative error message.

3. Things that act as selectors get mixed up with things that act as property assignments.

   device {
     name = my-tablet
     active_area_size = 255, 160
   }
   

   The name might have been more appropriate in device[name=my-tablet] { }, not next to active_area_size that is assigning a property.

[vaxerski]

this should move to https://github.com/hyprwm/hyprlang/

Possibly hyprwm/hyprlang#13