Naming convention / consistency guidelines

[Root-Core]

As we had some discussion in #5700, we should establish naming conventions.
The bike-shedding is real, so we might continue here until we come up with something usable.

Some ideas that have some consent:

• No negation (no no_ prefix)
• No enable / disable prefix / suffix
• Use snake_case (underscores), not kebab-case (hyphens, even if it sounds delicious)
• Consider to bundle variables with the same prefix into one category (kb_* -> keyboard { * })
• Use categories, if multiple variables affect some function (eg. logging)
• Dispatchers that toggle something should be prefixed with toggle (pin -> togglepin)
• Have consistency across different sections (gaps_in in general, not gapsin in workspaces)

Some ideas that have no consent yet:

• Should we use present tense for naming, not past tense? (enabled -> enable)
• Should variables names feel "switchable" with on and off? (eg. while_typing = off or hyprland_logo = on)
• Should the default config default to on and off? (with exceptions where it does not make sense)
• Should different rule types use the same delimiter? (general = comma / workspace space)
• This is a breaking change, how to implement / communicate it?
• Should we implement a conversion tool / script and should it be executed automatically?
• Should we establish a new file extension for the config?
  unique file extension desireable? hyprlang#13
• Will there be ever a Hyprland 1.0? (we don't need consent in this matter)
  unique file extension desireable? hyprlang#13 (comment)

[P9EA5Y]

Consider to bundle variables with the same prefix into one category (kb_* -> keyboard { * })

Use categories, if multiple variables affect some function (eg. logging

We have to determine the threshold for amount of attributes before they are dedicated a category.

Dispatchers that toggle something should be prefixed with toggle (pin -> togglepin)

This can potentially be merged into the switchable section.

Should different rule types use the same delimiter? (general = comma / workspace space)

Possibly modify Hyprlang to have parentheses around parameters separated by comma? We can then have more readable multiline config structures.

Should we implement a conversion tool / script?

We would likely have to create documentation matching new attributes with their legacy counterparts regardless, would not be much more difficult to write a conversion script in Bash.

Should we establish a new file extension for the config?

It appears to me that Vaxry has already migrated Hyprcursor to the new .hl extension, since we are implementing breaking changes, it be the perfect time to migrate and maintain consistency.

[Root-Core]

We have to determine the threshold for amount of attributes before they are dedicated a category.

Maybe > 1, as we should avoid breaking changes in the future.

Example: Threshold 4
If there are 3 attributes - which is fine - and we add another later, we would hit the threshold.
If we were to enforce the policy now, we would have to introduce breaking changes.

This can potentially be merged into the switchable section.

What do you mean by that?

Possibly modify Hyprlang to have parentheses around parameters separated by comma? We can then have more readable multiline config structures.

I don't know. I'm thinking about implementing an idea I had, to combine multiple windowrules.. and this could also be a beneficial addition to other places. Just like we do it with "executing with rules". A generic solution would be nice.

We would likely have to create documentation matching new attributes with their legacy counterparts regardless, would not be much more difficult to write a conversion script in Bash.

Sure, somebody will implement it regardless.
I'm just unsure if we should apply it automatically.
If not - which is most likely - we need to cater a compatibility layer.. which spawns some maintenance burden.

My best take yet: Convert it into the new format, but leave the old files unaltered. Load only the new file(s).

It appears to me that Vaxry has already migrated Hyprcursor to the new .hl extension, since we are implementing breaking changes, it be the perfect time to migrate and maintain consistency.

That's the idea. 👍🏻

[P9EA5Y]

Maybe > 1, as we should avoid breaking changes in the future.

I agree, we do have to reduce the amount of breaking changes as this project gains popularity.

What do you mean by that?

We can use switchable for them, for instance pin on, pin off.

I don't know. I'm thinking about implementing an idea I had, to combine multiple windowrules.. and this could also be a beneficial addition to other places. Just like we do it with "executing with rules". A generic solution would be nice.

It's the perfect time for changes like this, and I feel there should be more to it, potentially dedicate another discussion/issue to Hyprlang syntaxes?

[Root-Core]

We can use switchable for them, for instance pin on, pin off.

And something like pin toggle or group toggle?

It's the perfect time for changes like this, and I feel there should be more to it, potentially dedicate another discussion/issue to Hyprlang syntaxes?

I don't know if I will find the time to implement it right now. Implementing it for the rules in Hyprland shouldn't be complicated at all. A generic solution would be better though, and I haven't looked into the Hyprlang code yet.

[P9EA5Y]

Sorry for ghosting, had some troubles with my devices.

And something like pin toggle or group toggle?

For instance, attribute pin should just be pin, it would look something like pin: on and pin: off, etc.

I don't know if I will find the time to implement it right now. Implementing it for the rules in Hyprland shouldn't be complicated at all. A generic solution would be better though, and I haven't looked into the Hyprlang code yet.

I will take a look at it over this weekend, we can always implement a temporary translation layer if it seems too integrated into Hyrplang.

This might be too much of an overkill, but may I suggest static typing and potentially a stricter syntax for Hyrplang, and a configuration syntax guideline for the community.