The KM Manual says:
You should generally not use a Typed String trigger that simulates deletes in a non-text typing context, as the simulated delete keystrokes could be destructive.
For all fans of Typed String triggers (and single key triggers).
BTT has now found another approach to solve this problem. This also benefits KM users who use both apps. By default BTT blocks the Keyboard input from reaching other apps. But it doesn’t block the input from reaching BTT, which then can reach KM. Since there is nothing to delete any Typed String can be safely used (like a shortcut) in any environment to trigger macros.
I hope I have summarized this more or less correctly.
For those who want to read the KM manual the link is here:
I don't see why this is a "problem." Any programmer has to be aware of what his macro does in both typing and non-typing contexts.
I couldn't find the corresponding documentation for BTT.
It is a double one. First, what is typed and then what is deleted. I can't say exactly how great the danger really is of doing something bad. But I'm sure you know what it's about.
Because it hasn't been documented yet. I tried out the new feature yesterday and what I've noticed so far is very positive.
I think I found the BTT documentation here:
It specifically says that this "new feature" "will not block the keys from reach the app," as opposed to the idea that it "blocks the keyboard input from reaching other apps."
So maybe I'm quoting the wrong BTT feature. Are you talking about a different feature?
You have found what was previously correct. BTT worked in the same way as KM. As I said, the new feature is not yet documented.
Edit: To explain this in more detail. There are of course various ways to use the new function. What works for me is the following. Example:
double tap cmd --> activates the key blocking. This means that everything that is typed now is only passed on to BTT (to no other app)
Type "l" for "go to last front app". Or type "last" or whatever you want.
The macro is executed and the keyboard is unblocked again. Everything is as before.
This can also be done completely differently, it's just an example.
It's interesting to hear about.
For those who wish to use KM for such a workflow, using
Trigger Macro by Name seems to me to be just as efficient – but of course, as always, it all depends upon one's setup, requirements and preferences (standard disclaimer!).
Yes, "Trigger Macro by Name" is great. The main differences are probably:
- The trigger, which is not a string. You have to press Enter.
- The window is useful if you want to search for macros. Otherwise rather not.
@Airy In case you are interested. Here is a brief initial explanation of the new feature from the developer.
"Two new interesting actions that can allow for some new multi-letter keyboard shortcuts: "Start Blocking Keyboard Input" and "End Blocking Keyboard Input". Additionally a new variable in conditional activation groups that allows to test whether BTT is currently blocking keyboard input. This can be quite useful when combined with Key Sequences, because by default Key Sequences pass any input to the system - which can lead to lots of conflicts. If your key sequence first activates keyboard blocking, the system won't receive text input anymore. So for example you can define a Key Sequence ctrl + ctrl to disable keyboard input. Then you can have a second Key Sequence "a + b" (that is only active while keyboard blocking is active via a Conditional Activation Group). Now assign the "End Blocking Keyboard Input" action in addition to your desired action to that a + b Key Sequence."