Actually it does seem to measure the time. If you wait for about 5 seconds after typing "S + space" before continuing typing the trigger (typing the second space), the macro is not activated. So, there is a timeout going on, but not the 1 second you would like. I think most people would find 1 second too short and 5 seconds feels like a deliberate break.
But to improve the reliability of your existing "s + space + space" trigger I would probably just change to "s + space + space + space"
Therefore it would be good if you could set the time yourself. I will try triple space, but it seems not ... intuitive to me. Thanks @Zabobon
I'm obviously still missing something... The Control key is on the keyboard so you don't have move your fingers away, and I'd think that it's a lot less of an interruption to do s for s and ⌃S for Safari than it is to do "s and wiggle the pointer" for s" and "s then wait a bit" for Safari -- especially given that you are far more likely to want to type an "s" than you are to want to activate your browser.
And writing fast is surely irrelevant when/after activating Safari? You want to be able to type fast while you're actively typing, and all these workarounds seem to be designed to slow you down instead!
KM can't see into the future and can't read your mind. So it has to wait a "reasonable" amount of time after you type a letter and then assume that was an intended "nothing happened". And it has to do that every time you type that letter (slowing things down) and assume "nothing" regardless of why you delayed (lots of false activations of the "nothing" events -- see also "I think about something for a moment and then accidentally type space again").
For typed string triggers -- part of choosing reliable triggers must surely be to avoid accidental ones. I'd hazard that space-space is quite a common mistake, be it from a twitchy thumb or your described scenario above, which is why an uncommon mistake like @Zabobon's suggested sqq would be a better trigger choice.
But the problem with using a typed string trigger is that you are effectively limited in where you can use it, for fear of the unintended consequences of the simulated deletes. And that makes it difficult to have one "Let's launch Safari!" trigger since there's no way of telling if you are or are not in an active text field. YMMV, but I'd be much more productive having ⌃S launch Safari everywhere rather than different triggers in different contexts.
Lest the above seem overly negative -- I'm going to carry on with this because a) it intrigues me, and b) I can think of cases where unmodified keypress triggers like you describe could be useful eg for someone who has trouble hitting chords and so can't use even standard shortcuts.
Dear @nige I hope you are not angry with me. I wouldn't like that at all and it certainly wasn't my intention. I actually didn't explain this in more detail because hardly anyone cares. But if you want, I'll be happy to explain. Open Safari is just a "placeholder" an example of an action that everyone understands. In fact, it's about completely different actions in my writing program (Scrivener). But an action is an action. If I understand how it works with Safari, I understand it for everything, I think.
Concerning the Control key: When my fingers are on the keyboard, I reach exactly two modifiers with my thumbs without problems and without looking: left and right command. I could use control with my little finger, but I'm not used to it. So I would have to look to the keyboard and use another finger. This interrupts my writing flow.
I know normal people probably don't understand this. I'm a journalist, I'm crazy with a certificate.
So I mainly used the two command keys, left and right of the spacebar. I also have an app that allows me to assign different actions to the left/right modifiers. So left ⌘+a does not do the same as right ⌘+a. Or I double tap left or right ⌘. Or I hold left ⌘ and double tap right ⌘ to trigger an action. Things like that.
Single key triggers would be really useful for me, if they worked. But they don't, for known reasons. What could be better than triggering different actions with short/long press keys? Even more so when these keys are always directly under my fingers? That's probably why I'm absurdly still looking for a good solution, and a little bit also because I enjoy it.
The second best thing is strings. I use them often but only in my writing environment.
And the third best is gestures on the trackpad. I have to take my fingers off the keyboard, but I don't have to look.
I hope that makes it a little clearer for you 
i understand and i also do not understand. Let's take the example of "if the mouse moves". I press a key, KM waits 2 seconds to see if the mouse moves and then does what it does. KM doesn't have to see the future, it just has to wait to see what the future brings. Why can't KM wait 2 seconds to see if a key is pressed or not? Probably my logical abilities are not enough to see this correctly.
Okay, I think I have a kind of solution for your specific use case is "S + space + space" typed quickly launches Safari and typed slower does nothing.
Basically, the 30 second timeout on the first green Action means you type the "S" in your own time and if you don't double-tap the space bar within that time the Macro will do nothing and just stop.
And the 0.25 timeout on the second green Action means you have to follow that first space with the second space quite quickly (similar speed to a double-tap on the mouse).
So typing S followed by double-tap on the space bar launches Safari.
If you type "S + space + space" slowly the Macro does nothing.
EXAMPLE Open Safari with S + space + space (if typed quickly).kmmacros (18.7 KB)
@Zabobon you good soul, that's really, really kind of you. I should have told you that because of such and similar limitations for strings I use another app where I can set everything exactly to my liking. I'm sorry 
Ah, I thought that was what you were actually trying to do with all this - open Safari by just typing letters in a certain timeframe in a text app? 
Which is fine and as @Nige_S has said the best approach is to have the trigger string text as something you wouldn't type by accident. Then you don't have to get into all this timing stuff.
Yes, I am sorry. The question is how much to tell without boring people with unnecessary details and protecting the very helpful people in this forum from having to read entire novels.
Not at all! You're making me think and you're reminding me that we all have different ways of doing things -- both good for me 
I understand more about your "modifier restrictions" now. For me, little finger Control key is as second nature as little finger Shift, perhaps because I've always used an extended keyboard. But if it doesn't work for you, it doesn't work.
Except we do, because it's often highly relevant! Just as your keyboard constraints are important, so's your choice of placeholder action -- Safari implies a change of context to one where typing is no longer important, whereas A N Other action that happens in the context of Scrivener is another matter. It also opens the door to other potential solutions which wouldn't be worth considering if you did actually want to open Safari.
Exactly. Because it can't see into the future it has to wait -- not only does that introduce a delay, but anything dependent on timing is susceptible to mis-timing. The confusion is much reduced, however, when the event you are waiting for is completely different to your trigger event -- so your "keystroke trigger, mouse wiggle cancel" has possibilities.
Worth noting that a specific keypress would also be distinct enough -- you could, perhaps, do "Pause until key condition 'ESC is pressed'". I've used the ⌘ key here, even though that may not suit you (although I'm guessing that one of your left- or right-side ⌘ keys hasn't been remapped!).
Keypress S.kmmacros (4.1 KB)
You'll have to "resend" the "s" keystroke on cancellation.
You could also do the same, but using "s" as a typed string trigger. That would get you built-in case sensitivity (if that matters) and you could choose whether to resend the "s" on cancellation or to not simulate the delete and then do that as an action in the "not cancelled" branch (I've done the latter):
Keypress S as TST.kmmacros (4.5 KB)
Obviously the downside to both is that you have to take a deliberate "will cancel" decision rather than just carry on typing as normal -- but if you're amenable to the mouse-wiggle method you might find these slightly better.
Otherwise a "proper" typed string that is both convenient for, and unique to, you might be the best approach -- the few I have use ; as their "special character", eg ;st; because that's an easy "right little finger" character for me and I'm very unlikely to type ; without a following space or newline (JavaScript if statements notwithstanding...).
Thank you very much @Nige_S . Let me experiment a bit with your ideas...
Hold on a minute...
I was having my tea and suddenly thought "Hang on, half these problems are because we are trying to do everything in one macro. What if we used two?".
"Catch Char" is your trigger macro, enabling "Canceller", pausing for 2 seconds, then deleting the last character typed before activating Safari. "Canceller" is triggered by an "any one character" typed string regex and cancels "Catch" before disabling itself and re-enabling "Catch".
You should start with "Catch Char" enabled and "Canceller" disabled, although if you don't it'll only misbehave on the first run.
One issue is that it only works for a typed second character (including Return/Enter) and not bare modifiers or shortcuts (ie typing "s" then ⌘V will delete the last character of the pasted string and activate Safari -- unless you've carried on typing).
It hasn't been heavily tested, and I'm quite a slow typist. Let me know how you get on!
Single Char Catcher Macros.kmmacros (6.2 KB)
In limited testing, this seems to be working for me:
Example Macro.kmmacros (2.8 KB)
The key seems to be the semaphore lock (though it did work more often than not without it for me, it still seems better to include for a macro like this) and these timeout settings on the Pause Until Change action:
From what I could tell, an earlier attempt at a similar macro didn't work because the timeout wasn't set to abort the macro.
@Nige_S , That is great! Really! Of course, I haven't been able to test it for a long time yet, but from what I can see so far, it works absolutely reliably. There may still be a small opportunity for improvement. I'll have to test this a bit more and get back to you. 
Hi @gglick - I think this is doing the opposite of what the original post was asking, which is:
Type a letter and do nothing for 2 seconds = something happens
Type a letter and continue typing = nothing happens (apart from normal typed letters)
I can't see how to adapt your Macro to do that. It is surprisingly tricky and looks like @Frankb's two Macro solution is the only one so far.
@Zabobon I do not know what you mean. The macro does exactly what I wanted ... with a small problem that I'm still thinking about. And yes, I was always convinced it needed two macros. 
Ah, sorry, I misunderstood you 
Ah, you're right; I completely misunderstood. Never mind then.
I've spent a fair bit of time thinking about this conundrum and, in the search for a multipress macro that would accept fast typing, I came up with the exact same idea as @Nige_S. However, you'd have to be careful about what was in focus in a given app, as automating a deletion could have unforeseen consequences.
One thing that could remedy that would be to add a section that checks that the character to the immediate left of the cursor matches the hotkey trigger. If it doesn't, the deletion is skipped. I still think it's more prone to misbehaviour than I'd be comfy with though.
@Nige_S and all the other friendly people who try to help me. I apologize for what comes below, but my too small brain must imagine it figuratively .…
Nige, you like tea, right?
Imagine we are sitting at a empty table opposite each other. I am me and you are KM. I put a cup of tea on the table. Now there are two options. I drink the tea or you drink it. We agreed, you wait x seconds. If I haven't drunk the tea in that time, you drink it.
Option 1: I put the tea on the table (= press "s"). I take the cup before the x seconds are over and drink the tea (= after "s" another character is pressed). You have nothing to do.
Option 2: I put the tea on the table (= press "s"). I don't drink the tea even after x seconds have passed (= after "s" no further character is pressed). Now you become active and drink the tea (= open Safari).
This is how the macro works now, right? And it works fine.
But what do we do if there is already a cup of tea on the table before I put my cup down? For this case we need an additional agreement. The Deal is: If there is already a cup on the table, you do nothing, as in option 1. „Already a cup of tea“ (= if there is already a character in front of the „s“). You wait until my cup is alone on the table, only then you may drink it (= open Safari)
Does anyone understand this nonsense? And can that be done?
