Synthetic events can cause an infinite loop

[0ion9]

shift + s
    xdotool type S

This is an unrealistic example; my actual use case involves conditionally passing the captured event to the current window (so I can't use ~, it will unconditionally pass on the event)

AFAICS the fix involves ungrabbing the key immediately before executing the command, and regrabbing it after the command returns.

That still leaves the possibility of forking commands causing a loop, but nobody can do anything to avoid that, I think, aside from just not doing things that cause race conditions :)

[anko]

A more local way to implement that would be to create a cancelable-replay keysym modifier (maybe ~~ or ?), for which a command exiting with a non-zero status indicates the event shouldn't be replayed.

I'm proposing a different modifier because I imagine ~ is allowed to run the event replay and the command in parallel. We probably want to keep that optimisation, so you can run time-consuming commands without blocking/lagging the UI.

[wawe]

One way of working around this is to pass the synthetic event directly to a specific window.
E.g. to pass an event to the currently focused window using xdotool:

shift+s
    xdotool getwindowfocus type --window %@ S