You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SUPER+J (Toggle window split) raises "Runtime error in Lua: no such layoutmsg for scrolling" on scrolling-layout workspaces #14866
Pressing SUPER+J ("Toggle window split") on a workspace whose layout is scrolling pops an error notification:
Runtime error in Lua: no such layoutmsg for scrolling
SUPER+L ("Toggle workspace layout", omarchy-hyprland-workspace-layout-toggle) deliberately puts workspaces on the scrolling layout and persists it to ~/.local/state/omarchy/workspace-layouts/<id>.lua. SUPER+J then hits the error — two stock default bindings combining into a runtime error.
Steps to recreate:
Press SUPER+L on any workspace -> notification "Workspace layout set to scrolling"
Press SUPER+J -> error notification "Runtime error in Lua: no such layoutmsg for scrolling"
Deterministic repro without the keybinding (workspace 1 is on scrolling here):
$ hyprctl activeworkspace -j | jq '{id, tiledLayout}'
{
"id": 1,
"tiledLayout": "scrolling",
"name": "1"
}
$ hyprctl eval 'hl.dispatch(hl.dsp.layout("togglesplit"))'
error: =[C]:-1: no such layoutmsg for scrolling
Root cause: SUPER+J is bound unconditionally to a dwindle-only layoutmsg in /usr/share/omarchy/default/hypr/bindings/tiling.lua:
togglesplit doesn't exist for the scrolling layout, so the dispatch raises a Lua runtime error that surfaces as a desktop notification.
Expected: a clean no-op (or a friendly "not available on this layout" note). Possible fix: guard the binding against the active workspace layout, or make a failed hl.dsp.layout dispatch degrade to a silent no-op instead of raising.
Full omarchy-debug --no-sudo --print output is in omarchy-debug.log in this package (4592 lines; key excerpt below).
Thanks for the clear repro! This is the same bug as #7556. There are a few open fixes: #11863 (guards the binding in Lua and uses consume_or_expel on scrolling), #6924, and the new #14867.
This is the same bug as #7556, so I'm closing this one in favour of it. Both report that the stock SUPER + J binding in default/hypr/bindings/tiling.lua always dispatches the dwindle-only hl.dsp.layout("togglesplit"), so on a workspace that SUPER + L has switched to the scrolling layout it raises no such layoutmsg for scrolling. Same binding, same cause, same branch. #7556 was filed first, on 4.0.0.
I checked current quattro and the binding is still unguarded there, so the bug is real and still open. Two open pull requests fix it: #6924 and #11863. Choosing between them is up to the maintainer. #14867 has been closed.
Classifying this as a bug and calling it a duplicate were each checked separately by Codex Medium as a second opinion, and it agreed both times. If I've got this wrong and it's a different problem from #7556, reopen it.
Activity
Safely handle window split toggle on scrolling workspace layout (omac…
jandrusk commentedon Oct 12, 2026
Thanks for the clear repro! This is the same bug as #7556. There are a few open fixes: #11863 (guards the binding in Lua and uses
consume_or_expelon scrolling), #6924, and the new #14867.omarchybot commentedon Oct 22, 2026
This is the same bug as #7556, so I'm closing this one in favour of it. Both report that the stock
SUPER + Jbinding indefault/hypr/bindings/tiling.luaalways dispatches the dwindle-onlyhl.dsp.layout("togglesplit"), so on a workspace thatSUPER + Lhas switched to the scrolling layout it raisesno such layoutmsg for scrolling. Same binding, same cause, same branch. #7556 was filed first, on 4.0.0.I checked current
quattroand the binding is still unguarded there, so the bug is real and still open. Two open pull requests fix it: #6924 and #11863. Choosing between them is up to the maintainer. #14867 has been closed.Classifying this as a bug and calling it a duplicate were each checked separately by Codex Medium as a second opinion, and it agreed both times. If I've got this wrong and it's a different problem from #7556, reopen it.