This plugin assists with Hyprland's 0.55 migration from Hyprlang to Lua configs, using Neovim's built-in Treesitter parsing. Made for fun (and to convert my config over).
The idea is to provide near-instant transpilation from Hyprlang to Lua on a best-effort basis to help users get 90% of the way to a fully converted Lua configuration, where they can then use LLMs and/or manual editing to finish the rest.
tree-sitter-hyprlangparser + queries (e.g. with nvim-treesitter, run:TSInstall hyprlang).- Neovim 0.12+ is officially supported. This might work with 0.10 and 0.11 as well.
vim.pack.add({
"https://github.com/pynappo/hyprlang-to-lua.nvim"
})In a hyprlang buffer, selecting Hyprlang text and running :HyprlangToLuaSplit will open a new split containing the
autogenerated Lua code for the selected Hyprlang text. To convert the whole buffer, you can select it with
:%HyprlangToLuaSplit.
The intended workflow is that if the auto-generated code looks good, you can run :saveas ~/.config/hypr/hyprland.conf
(or wherever you want to save it). Or you can cherry-pick segments and yank/put them as you see fit.
Any comments by hyprlang-to-lua (warnings, enclosing comments denoting autogeneration) will have hyprlang-to-lua in
them for easy searching and deletion.
If you want headless operation (i.e. to pipe the result into a new file), you can run something like:
nvim --headless --cmd "autocmd VimEnter * lua
require('hyprlang-to-lua').convert_to_stdout_then_quit('$XDG_CONFIG_HOME/hypr/hyprland.conf')"In general, the most common configuration segments should translate properly. Please report any issues as you find them.
Notable details/limitations:
- Conversion of Hyprlang variables in keybinds (e.g.
$mainMod) is implemented. Options that are assigned a single variable should convert as well. String interpolation (i.e. strings combined with variables) is only implemented for keybinds at the time of writing. - Most common keywords are implemented (execs, window rules, monitors, animations and curves, etc.).
- Most, if not all dispatchers should translate properly.
- Source statements should work if the source file being pointed to is under the
hypr/directory, will be commented out otherwise. - Rules with multiple matchers of the same type (e.g. two
match:classrules in a window rule) will keep only one of them. hyprlang-to-lua will leave comments about this, but it won't automatically generate the extra code for you if you want to preserve the same behavior. - There's some amount of effort to keep the generated Lua looking reasonable (in terms of line length, table formatting, indentation, etc.)
- The outermost levels of Lua tables have their key-value pairs by the order in which the keys were listed in the original Hyprlang config, whenever possible. Inner tables do not have this same sorting (yet?), and are instead sorted alphabetically.
- Gestures have very minimal processing on the parameters for the dispatchers, will need to go over all the actions and implement fixes on a per-action basis.
- Expose indentation settings.
- (Not sure:) Hyprland's auto-generated lua stubs suck - most things are loosely typed, and many tables are missing fields only found on the wiki. It would be tedious but it'd probably be useful to override the classes with significantly better types to help Neovim users, and it would be cool to upstream the work.
- Formatting is never going to be as good as an actual formatter like StyLua.
- Any lua optimizations significantly more complicated than the current optimization pass: just combining similar exec commands (e.g. blocks of exec-once) into a single hl.on call.
- (maybe up for debate) Supporting variable arithmetic - lack of actual usage and just annoying to implement.
Requirements:
- lua-language-server
- Neovim
- mise (for dev tasks)
- Hyprland 0.55+ (or have the lua stubs available at /usr/share/hypr/stubs/).
- Used Gemini for writing some string manipulation code (particularly, complex lua pattern strings).
- Pretty much everything else (including this README) is human-written.