I just noticed that in the Barebones applications (BBEdit, TextWrangler) KM’s typed string trigger is not working properly if I have a user prompt near the beginning of the macro.
If the typed trigger string is longer than a couple of characters, then not all characters are deleted. It is as if the deletion stops in the moment when the user prompt comes up.
I tried it in some other apps (TextMate, Textedit, Notes, Script Editor, …) and everything is fine there.
Has this always been like this or is this new since KM 7.2.1?
I would guess that those apps are just being a bit slow processing the keys (which is surprising). Because of the keyboard vent queue, there is probably nothing I can do about it short of just slowing down keystroke typing. You can do that using the Set Action Delay action.
I would suggest you simply add a very short pause at the start of your macro. 0.3 seconds was sufficient for me.
Thanks for the confirmation. Since I never noticed it before I wasn’t sure if it was KM 7.2.1 or maybe a suboptimal configuration of my BBEdit (autocompletion interfering, or whatever).
The curious thing however is that when I disable the user prompt, the insert action patiently waits until the trigger characters are all deleted.
It is not that it patiently waits, it is that all the keystrokes go into the same event queue, so it really does not matter how fast or slow the application is, it will process all the events in order. The problem with the prompt is that that window appears while there are still events (delete keystrokes) in the event queue. And since Keyboard Maestro cannot see the event queue and tell when it is empty, there is no way to wait the required amount of time, it has to be done just with a fixed delay, which is not enough in this case.
When typing into BBEdit, KM’s user prompt window aborts the event queue (the one with the Delete keystrokes) if it still isn’t finished. The only remedy is to add delay, for example in form of a Pause action.
But when typing into, for example, TextMate, KM’s user prompt window does not abort that event queue. The deletion of the trigger string continues while the user prompt window is already on screen. (To make this clearly visible use a long trigger string of 50 chars or so.)
So, BBEdit’s “uniqueness” doesn’t seem to be a slow processing of the keys, but rather something different that I don’t get.
Peter, please note that this is not a usability problem for me since I usually never use KM for snippet expansion with user prompt in BBEdit. I’m just trying to understand what makes BBEdit so “outstanding”
No. Keyboard Maestro simulated 17 deletes, and then runs the macro. So the event queue has 17 deletes in it, which BBEdit is processing, it processes perhaps 6 of them in the time Keyboard Maestro Engine expects it to handle all of them. Then the macro pops up the Prompt For user Input window which steals the keyboard input focus from BBEdit. Essentially the deletes are now processed by Keyboard Maestro Engine, though probably before the dialog is actually ready for them which is why they don’t do anything.
On the other hand, if there is no prompt, then the event queue has 17 deletes followed by a bunch more text, and BBEdit processes all of them in order in due time.
With non-Barebones programs the keyboard input focus obviously does not get stolen by the user prompt. (I tested it with up to 70 chars in the trigger: deletion continues while the prompt is already on screen.)
Presumably BBEdit is being slow at processing the characters. Also, BBEdit is very very old, it is possible it is using some old tech for processing keyboard events that has other limitations.
Presumably BBEdit is being slow at processing the characters.
It doesn’t seem so to me. The speed of the apps varies, this is true. But with a trigger of 70 chars none of the apps I’ve tested is fast enough to delete the whole string before the prompt pops up.
The difference is that BBEdit stops when the prompt pops up while the others continue to delete (with the prompt already on screen).
it is possible it is using some old tech for processing keyboard events that has other limitations.
