Repository navigation
omarchy-menu-keybindings Lua stub makes ipairs infinite (Super+K hang with plugins using hl.get_windows) #15216
Description
Summary
omarchy-menu-keybindings (SUPER + K) builds a Lua bind cache by dofileing ~/.config/hypr/hyprland.lua against a stub hl. That stub’s self-referential noop makes ipairs(hl.get_windows()) never terminate, so any Hyprland toggle/plugin that iterates windows at load time wedges the cheatsheet at ~100% CPU until kill/restart.
Reproduced with duncio/omarchy-cava (backdrop visualizer that recovers its window via ipairs(hl.get_windows()) on load). Same class of bug will hit any future toggle that does the same.
Environment
- Omarchy 4.0.4-1
- Hyprland 0.56.2
omarchy-menu-keybindingsfrom packaged/usr/share/omarchy/bin/omarchy-menu-keybindings
Steps to reproduce
- Install a Hyprland toggle that runs
ipairs(hl.get_windows())at load (e.g. enableio.github.duncio.omarchy-cava, which installs~/.local/state/omarchy/toggles/hypr/omarchy-cava.lua). - Run
omarchy-menu-keybindings --printor pressSUPER + K.
Expected
Bind list prints / cheatsheet opens quickly.
Actual
lua child spins at ~100% CPU forever; cheatsheet never appears. Process tree looks like:
omarchy-menu-keybindings → lua (R, ~100% CPU)
Root cause
In build_lua_bind_cache, the stub is effectively:
noop = setmetatable({}, {
__index = function() return noop end,
__call = function() return noop end,
})
-- hl.get_windows → noop via __index; noop() → noop via __callLua 5.4 ipairs uses __index and stops only on nil. So ipairs(noop) yields forever.
The hang is during require("default.hypr.toggles") after bind lines have already been printed.
The same pattern exists in third-party scanners (e.g. keymap plugin scripts/scan.lua).
Suggested fix (Omarchy)
Make the scanner noop safe for ipairs / #:
noop = setmetatable({}, {
__index = function(_, key)
if type(key) == "number" then return nil end
return noop
end,
__call = function() return noop end,
__len = function() return 0 end,
})Optionally also set an env like OMARCHY_KEYMAP_SCAN=1 (keymap already honors this) so toggles can skip live bookkeeping intentionally.
Related
Plugin-side report: will link to duncio/omarchy-cava issue after create.
Diagnostic log locally: /tmp/omarchy-debug.log (from omarchy-debug --no-sudo --print).
Activity
AlxWolfenstein97 commentedon Oct 12, 2026
Plugin-side report (omarchy-cava infinite
ipairs(hl.get_windows())under the stub): duncio/omarchy-cava#1aholbreich commentedon Oct 12, 2026
This is #7025, the same
ipairshang through the scan's self-returning stub. #12124, #13979, #14243 and #14302 report it too (#12052 is already closed). The fix is #7564, which gives the stub real empty lists and time-boxes the scan.I reproduced your case with the real
omarchy-menu-keybindings --printin a sandbox (stubbedhyprctl, fake HOME seeded from the tree'sconfig/hypr), adding a toggle~/.local/state/omarchy/toggles/hypr/cava.luathat runsfor _, w in ipairs(hl.get_windows()) do end:quattro(4c1b4cb)default/hypr/qconsole.lua, so every user bind is listed without its dispatcher (also fixed by #7564)quattroSo on the current release the hang is exactly as you describe, and on
quattroit's hidden behind the other scan bug. Your plugin-side report (duncio/omarchy-cava#1) is still worth keeping; any toggle that walks windows at load hits this until #7564 lands.c4software commentedon Oct 19, 2026
@dhh friendly ping: this hang (and its duplicates #7025, #12124, #13979, #14243, #14302) is still present in the packaged 4.0.5-1, and a fix is already waiting in several open PRs. They all make the scan's
noopstub returnnilfor a numeric index soipairs()over a stubbed getter ends:luachild)Any of them would close this. More context from a real config in #7564 (comment).