Will hyprmod be considering lua config in the future?

[vitorf7]

This is very early days but somewhat recently hyprland introduced lua as the config language going forward in place of the "old" hyprlang config.

This article does mention many of the hypr* tools will eventually move in that direction but slowly.

I guess that means that somewhere down the line we could think that hyprmod would also have to be able to implement/use lua for the configuration.

Now I do not know whether or not hyprland will be compatible with say hyprland config being in lua and having other extensions or tools in hyprlang, but still wanted to raise this discussion as it is an interesting one to look into.

Any plans or thoughts on this?

[BlueManCZ]

Hey @vitorf7, thanks for raising this — it's a great topic to have on the radar.

I've been keeping an eye on the Lua transition since the announcement. The Lua commits have actually already landed in Hyprland, so the rough shape is visible, but I'd rather wait for a stable release before committing to anything — APIs at this stage tend to shift, and I don't want HyprMod to chase a moving target. As soon as it stabilizes, picking up Lua support is high on the list.

The good news is that the migration shouldn't be a big deal for HyprMod. A few reasons:

• HyprMod doesn't touch your hyprland.conf. It writes its own managed file (hyprland-gui.conf) and only adds a single source = ... line to your main config during first-run setup. So the surface area that cares about config syntax is genuinely small.
• The config syntax is isolated in one library. All Hyprlang parsing and serialization lives in hyprland-config, which HyprMod consumes. Adding Lua emission is a contained change there, not something that ripples through every page.
• Live preview won't be affected. HyprMod talks to Hyprland over its IPC socket (hyprctl keyword ...), and that runtime dispatch is independent of which language the config file is written in.
• The option metadata stays the same. Names like general:gaps_in, decoration:rounding, etc. don't change — only the surrounding syntax does (e.g. general:gaps_in = 5 becomes something like general.gaps_in = 5 in Lua). The schema HyprMod uses to know what options exist and what types they take is untouched — and hyprland-schema already learned to parse Hyprland's new ConfigValues.cpp metadata format that came in with the Lua work, so we're already a step ahead there.

So realistically the work boils down to: teach the config library to emit Lua, update the first-run setup to inject the Lua equivalent of the source line, and pick a format for the profile files HyprMod saves on disk once Hyprland's long-term stance on Hyprlang compatibility is clear.

Thanks again for opening the discussion!

[vitorf7]

@BlueManCZ I totally agree that it is way too early to be trying to adopt the lua config, at the very least till they say it is stable as you said, or at most till they say version X will completely deprecate the usage of hyprlang and therefore then we are forced to go to lua.

I had a feeling that most of the other hypr* tools have their own configs so even if hyprmod used lua it would not affect the other tools as each is loaded separately by their own configs.

I realised later that someone else had mentioned the lua stuff in another discussion, so on that sorry for raising this and you getting a notification and interrupting the work you were doing, I know how difficult it can be sometimes with personal work and then also having to maintain open source software. Thanks for the work though, it has been mega helpful to me as someone who is new to hyprland, trying to move away from Mac (even for work).

[BlueManCZ]

No need to apologize at all. Lua has been mentioned in another discussion, but yours is the first detailed post on it — and actually a useful one: it pushed me to write down the migration story properly and add Lua support to the roadmap, so anyone else with the same question can see where things stand.

You're spot on about the hypr* tools being independent — each has its own config file (hyprpaper.conf, hypridle.conf, hyprlock.conf, etc.) loaded by its own daemon, so they'll switch on their own schedules. Worth mentioning: I do have pages for the hypr* ecosystem on the roadmap (hyprpaper, hypridle, hyprlock), so once I get to those I'll get to see firsthand how each tool handles the Lua transition. We'll see how it plays out.

And really glad HyprMod has been helpful — thanks for the kind words!

[BlueManCZ]

Hello, HyprMod now supports Lua - #33. You can give it a try if you find some free time on your hands. If you eventually find something broken, please let me know. Feedback is really valuable at this stage.