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.
Trivial patch that simply changes the "demon" word to "daemon". As the
latter is the more common variant to designate a process toiling in
the background, I'm just assuming "demon" was a typo.
William Barsse
Tassilo Horn