Your description reminds me of a Schmitt trigger used in electronics. One can implement a Schmitt-trigger-like action in the digital domain with a state machine: S1: when a 0->1 event occurs, go to state S2. S2: when a 1->0 event occurs go back to state S1. (I think of the timer variant as a Schmitt trigger that deals with analog signals).

I have a problem shaped a lot like this in my “turn-orchestrator” for my agent harness. I’m tempted to solve it with timers (like “if no activity for 15 seconds, then it’s time to mark this as idled”), but it makes me itchy to solve a problem like that.

I seem to have not replied to the original thread again. This was meant as a reply to @Marek Rogalski's thread (https://feelingofcomputing.slack.com/archives/C0120A3L30R/p1775053630907069)

The event-based state machine analogy is surprisingly accurate - also for the Key Presser. It's because a "key" on the computer is not quite a boolean - at the OS level it's a sequence of "press" & "release" events. For example it's possible for a key to be "pressed" three times in a row, and then "released" once. Internally, most apps follow the Schmitt trigger model and maintain an internal boolean as the key state - but not always. And this can be used to trigger some fun edge-cases in many games - like faster movement or higher fire rate. The games can get pretty confused if the "release" events don't match up with "press"-es 🙂 Also fun - if you go even deeper, on the HID level, it's a mix of the two models. The keyboards sometimes report state transitions (pressed => released & vice versa) and sometimes they dump the full key state (list of pressed keys). All depends on the whims of the firmware. At the deepest level it's obviously just logic voltage levels. Source: I'm also developing a tiny hand-held keyboard https://github.com/mafik/keyer - hopefully one day it'll run Automat on it :P

This confusion isn’t restricted to games. I experience it in MacOS and emacs almost daily. The phobia against using “state” results in Greenspunian manual implementations of state machines using bad ideas like booleans and if-then-else instead of proper state machines. This just makes “reasoning about” sequencing much harder (and buggier) than necessary. BTW, a state machine is not just a switch statement, you need 3 functions per state (enter(), step(), exit()) - trivial to do, but bug-ridden if you build it manually with low-level constructs like booleans and if-then-else. @Marek Rogalski