Related to discussion here: How to `insert text by pasting` and not have it in clipboard after
I often do this now:
I would love if I didn't have to add that Delete Past Keyboard action every time.
I would like an option here:
That would be Insert text by pasting and clear clipboard after.
I don't want to use Insert text by typing as it's slower.
Thank you.
Just out of curiosity, what advantage would such an "option" have for you? Wouldn't both actions do the same thing, delete the clipboard?
I'll second this, as I'm yet to have encountered a situation where I don't want it removed.
Similarly, it would be great if activate application and pause until app is at the front could be a two-fer.
There are a bunch of these combos that make sense most of the time. I did manage to convince Peter that button presses should have a pause until button is enabled function built in, so perhaps there's scope for more integration...
In my case it would be useful because sometimes I simply forget to add the delete clipboard action and end up with cruft on my clipboard. Plus, I like to build my macros with the least amount of actions as possible to keep my plist file size low, so combining certain functions into a single action would help with that.
Ok, I don't have to understand, if it is useful for you, I also support it ... 
What I can say in addition to your support, BTT did not even have an action to delete the clipboard until recently. When I asked for it, the developer did something else: the action "insert text by pasting or typing" now bypasses the clipboard manager by default.
Yeah, +1.
Sorry @peternlewis but it seems that the vast majority of "insert by pasting" use cases would prefer to leave the clipboard stack intact.
Granted, I do this already with a subroutine (love you for those!) but…"think of the children!"
I have the action pair shown in the OP saved as a favourite, and there's an argument that this is as efficient, in terms of steps, as a new action with a clipboard cleaning option built in.
I don't see an argument against that kind of neat integration, but I suppose it's worth bearing in mind that Peter probably has plenty on his plate with a new release on the near horizon.
I am most definitely thinking of the children when I implement such features.
Indeed the clipboard is not restored specifically because it would be dangerous to do so and lead to problems that are complex in nature.
There is a large descriptions of the issues suroudning it in the FAQ Why is the clipboard not restored after any clipboard action?
It all relates to the intricacies of the the event queue, which means that UI events (such as key presses and mouse clicks and especially the ⌘V that Keyboard Maestro simulates to cause the Paste to happen) are placed in an event queue, which is then processed at a later time by the OS and then the current front application. Meanwhile the clipboard is set by explicit APIs that happen without delay. As such, the clearing of the clipboard to restore the previous clipboard has to happen after some period of time, which length is unknowable in practice. If it is done too soon, then the wrong clipboard will be pasted when the system and application eventually get around to processing the ⌘V. If it is done too late then you could potentially have Copy or Cut other information, which would then be destroyed.
So by all means, ignore the fate of the children and delete the clipboard immediately after the Insert Text by Pasting, Keyboard Maestro will not stop you doing this, but it also will not actively help you set yourself up for problems by adding an option to do this.
The Activate a Specific Application action waits until the application is at the front.
Of course, just being at the front does not necessarily mean that it will have opened any initial windows or otherwise be ready for whatever happens next.
Yes.
The issue remains. To see why the issue is there, let me break the Inset Text by Pasting into its two equivalent parts, which are Set Clipboard to Text, Type Keystroke Command V.
So regardless of what you do, the sequence is going to be (presuming you want to restore the clipboard)
The problem is that after Keyboard Maestro (or you by typing) add the ⌘V to the event queue, there is no way to tell when that event is retrieved from the event queue by the system, passed through the target application until it eventually decides it means “Paste” and reads the clipboard.
It could be any amount of time, and it depends on the system load, and there is no useful way to know when it happens. And therefore there is no way to know how long that pause needs to be. Too short and the wrong thing is pasted. But there is no way to know what “too short” is.
So perhaps we should err on the side of 'too long' and add a static, 0.3s pause (for example) after the clipboard has changed but before the clipboard cleanup.
I think in practical terms, this would usually be ok, but I take your point that it's a use at your own risk thing.
You could give the user the option:
...but I understand why you may not want to do this, particularly for new users.
Good find and very interesting!
Identifying programmatically added clipboard items might be helpful for knowing what is safe to remove, but I don't think it gets us any closer to knowing when pasting has completed, which seems to be the crux of the issue.
@peternlewis thanks very much for the detailed and informative responses. My little children are indeed happy.
