hl.dsp.window.cycle_next misbehaving when set multiple times

[giodueck]

I have a series of binds like this:

bind = $mainMod CTRL, H, cyclenext, prev
bind = $mainMod CTRL, H, alterzorder, top
bind = $mainMod CTRL, L, cyclenext,
bind = $mainMod CTRL, L, alterzorder, top

The idea is to be able to focus every window in a workspace, tiled or floating, regardless of its position. If a second monitor is to the right, a movefocus sometimes skips windows on the scroll tape to the right and chooses to instead focus the workspace on the other monitor.

I have a problem with the Lua translation of the cycle_next binds:

hl.bind(mainMod .. " + CTRL + H", hl.dsp.window.cycle_next({ prev = true }))
hl.bind(mainMod .. " + CTRL + L", hl.dsp.window.cycle_next())

The original behavior, for scrolling layout causes behavior similar to movefocus when all windows are tiled. With the Lua version, both binds move in the prev direction. Is this a bug or am I misunderstanding the docs?

[sagayda]

https://wiki.hypr.land/Configuring/Basics/Dispatchers/#window-1
The Lua cycle_next dispatcher doesn't have a prev parameter. The equivalent would be next = false. Additionally, it has tiled and floating parameters, so you can probably achieve what you want using only this dispatcher.

[giodueck]

Does this mean the supreme leader is fallible? https://forum.hypr.land/t/is-this-right-in-lua/1584

In all seriousness, the prev field does actually change the behavior of the dispatcher, but it does so for all binds, even if it should not for the second one.

[sagayda]

This might be a leftover from the previous configuration system - I honestly have no idea.

In all seriousness, the prev field does actually change the behavior of the dispatcher, but it does so for all binds, even if it should not for the second one.

I can confirm this, so it looks like a bug either way.