The "nop" command, as the name implies, doesn't do anything. The change isn't entirely frivolous ;-) Sending a "nop" command interrupts any in-progress "prev-next" sequence without any other side effects. Until a sequence is interrupted, all next/prev-window commands navigate the windows in the LRU order captured at the time of the first command in the sequence. A "nop" command can be useful if bound to a particular key _release_ event in Sway. For instance, if <Mod1-release> is bound to "nop" while <Mod1-Tab> and <Mod1-Shift-Tab> are bound to the "prev/next-window" commands, then releasing <Mod1> will be enough to refresh the LRU sequence for the next use of these next/prev bindings. This behavior feels more intuitive (at least to me) than the non-nop variation. One caveat though: there is currently an [outstanding bug in sway on release bindings](https://github.com/swaywm/sway/issues/6456) which prevents the described scenario from working exactly as described because the Tab/S-Tab key presses actually cancel the outstanding release action. There is however also a (non-merged) PR available that addresses the issue.main
parent
f484eb0420
commit
559bf941e5
1 changed files with 4 additions and 0 deletions
Loading…
Reference in new issue