The Trigger Macro by Name action is really a Trigger Macro by Name or Contents action.
… it will search all[1] of your active, enabled Macros whose name or contents[2] contain what you type. It is a character search, so it will also find Macro names and words that contain what you type.[3]
Would anyone agree that it would be very useful to have an option within the Trigger macro by name action to match on name only?
I know one could always type name: or n: in front of each word, but that’s too much UI friction and visual clutter for a macro that I use frequently.[4]
I did prepare a detailed explanation of how such an option would greatly suit my needs but decided to spare readers, because of course that’s all irrelevant if nobody else would also find such an option useful!
I know you want to hear yes from people, but I’ve never used that action. In fact, I’m embarrassed to admit I never knew it existed.
KM is a mature product and may not get as many dramatic upgrades as it has before, but I would like to see direct support for HomeKit, direct support with some AI model (preferably Siri AI in macOS 27), enhancements to display actions so I can present more information to the user (eg, a progress bar with support for a larger window, more lines of text, and more progress bars), a mechanism to detect the volume of sound coming out of the speaker (or into the mic), triggers for when the user moves the mouse to the corners of the display (since macOS now supports this idea), etc.
Note: This macro contains code written by Claude. If you don't want to use AI-generated code, this is not a macro you'll want to use.
I knew this data was available via AppleScript. I also knew it was beyond my skill level to retrieve it :). So I had Claude write two little JXA routines, after feeding it the .sdef file for Keyboard Maestro. The first extracts a list of macro names and UUIDs, where both the macro is enabled and in a macro group that's enabled.
Then that list is presented in a Prompt With List, with a rebuild option as the first item in the list.
The second JXA launches the selected macro by UUID, as the built-in Execute Macro action won't use UUIDs and can't accept variables.
Macros are always disabled when imported into the Keyboard Maestro Editor.
The user must ensure the macro is enabled.
The user must also ensure the macro's parent macro-group is enabled.
System information
macOS 26.6
Keyboard Maestro v11.1.1
The first run will take a few seconds, but the results are saved in a global variable, so future uses are instantaneous. Just call this macro instead of using the Trigger Macro by Name action.
An obvious extension of this would be to present the data in a two-column (macro name and group name) custom HTML prompt that resembles the Spotlight UI, with sortable columns, etc.
Another possibility is to put the list rebuild JXA code in a separate macro that runs on a timer, so it's always current.
But as this isn't a macro I'll ever use, I'll leave those enhancements to someone else :).
I’m sure nearly all of us are often surprised now and then by existing features in KM, and of course macros are the result of individual ways of working. I use Trigger macro by name as part of an idiosyncratic system that I find very effective but which I doubt anyone else has felt the need to adopt. If there were a vote for features, I would not expect Trigger macro by name and that’s all thanks to top it! I just wondered really whether, for reasons I have not imagined, anyone else might care about the limitation—or if you prefer, lack of limitation!—of that action.
Thanks for the macro. I shall continue looking into it, but in practice, I am wary of opening another (AI-manufactured) can of worms when the system I have is perfect apart from just one or two rogue entries finding their way into the prompt once in a while. That’s not such a big deal; if it ever really bothers me, I can tweak the contents of such macros so that they definitely won’t match. I suppose more than anything, it was just surprising that Trigger macro by name can’t actually be limited to triggering a macro by name! I think it unlikely, however, that anyone else will have ever found themselves troubled by that in the slightest.
Thanks, @Nige_S, but it’s the visual clutter that bothers me. I note the use of Applescript to generate the keystrokes. It had crossed my mind to use a concurrent subroutine to provide keystrokes, but Applescript would of course be a better way,
Thank you both again for the attempts at helping. As I mentioned, though, I thought it better not to bore everyone with the full details of why a “by name only, really” option for the action would be the ideal solution for me; suffice it to say, my existing method suits me just fine and in practical terms, I’m just being a perfectionist. Stating the background of my question meant that nobody had to ask why I cared about the issue but it perhaps distracted from the directness of the question:
I didn’t expect anyone to say yes, and I still don’t, but I had to ask!
I think the “Prepend” action needs to be moved into the “iF” block - otherwise the “rebuild” items keeps getting added to the top of the list every time the macro runs
I usually turn off DM on sites like this, because I don’t think I would be able to keep track of private conversations in my head. Every name on this website feels like the same person to me.
I do enjoy writing software in KM, and taking someone else’s solutions would feel like reading a solution to a crossword puzzle that I’m working on. I prefer solving my crosswords without help.
Reminder that the Trigger Macro By Name search field can be set to show default text, so it could always show n: when run. Upon running the macro, a quick press of the right arrow key would place the cursor to the right (which of course could be automated using a Type A Keystroke Acton as part the Trigger Macro By Name macro).
Unless I’m very much mistaken (I won’t check right now, because it’s academic to me, but I’m pretty sure I’m right!), that would cover the following text up to the next space only. Then another n: would be needed for the next word. That’s in theory; in practice, it would not necessarily be an issue—but then, none of this is a major issue. Each workaround brings trade-offs.
There is one sensible solution to the fact that trigger macro by name acts like trigger macro by name and/or contents and that is to add an option to match by macro name words only. Everything else is a workaround. The question remains:
Then I'm going to say a definite "No!" -- from a UX perspective.
It's Bad Form to have the same dialog working in two different ways without some indication of how it is working. At the moment that's shown by the prepended n: (or whatever filter you use) -- how would you differentiate if that wasn't there?
There may be a case for a subtler indication, but that would have to be outside the text field and could make changing filters on the fly more difficult. But I certainly wouldn't be averse to that.
How about a held modifier key to change behaviour? ⌥ is out, since that will open the selected macro for editing. I think ⌘ is available, though.
A “filter” has already been applied by the creator of the macro and its sole user (me). Would you have the wording changed to “Trigger Macro by name using only the macros in the smart group Macro by Name”, remove the ability to match from a specified macro group, or trust the user? I think with KM, the philosophy is that you give people lots of options and tell them to think about what they are doing. There are, after all, a lot of important settings that can be concealed behing the cogwheel of some actions.
But let’s say you’re right (and you might well be; I’m just arguing from my current perspective). The obvious alternative to adding an option to this action would be to create a sibling action, Trigger Macro by Name but not contents (named here for illustrative purposes only).
Too arcane.
Well, the record shows that I can get a bit muddled at this point, but my understanding at the moment is that, in that example, an n: would be needed before each word, because a space would reset the context to “any” (including contents). But again, this is an academic point to me. Rather than fiddling with search syntax, a Trigger Macro by Name action that strictly triggers a macro by name (and not contents) is what I have in mind. It seemed to me to be a reasonable expectation of an action with that name, so that was my starting point, and it’s still my ideal destination. I just don’t expect it will happen unless anyone besides me has any practical need for such behaviour from this action (or a new sibling action).
That’s interesting, and it’s an example of “stylometry.” Recently, I had been thinking of writing a KM macro that identifies authors by their style of writing, but I no longer want to do that because it’s so easy to do using AI. I took your own words from this thread, and also @griffman’s words, and asked an old AI model to compare them to see if they were written by the same person. The conclusion was wrong, but here’s what it said:
Determining the probability that two pieces of text were written by the same person involves analyzing various stylistic, syntactic, and semantic features. While I can't provide a precise probability without extensive computational analysis, I can offer some observations that might inform such an analysis:
Writing Style and Tone: Both paragraphs exhibit a detailed, technical tone with a focus on explaining software functionality and personal problem-solving processes. The use of hypothetical scenarios, questions, and self-reflection is consistent in both pieces.
Vocabulary and Language Use: There is a shared use of technical terms related to macros and automation (e.g., "macro," "UUID," "AppleScript," "JXA," "Prompt With List"). Both authors also use similar phrases like "obvious alternative" and "reasonable expectation," suggesting a similar thought process.
Sentence Structure: The sentence structures are complex and often include multiple clauses, which is a characteristic of both paragraphs. The use of parentheses for asides and clarifications is also prevalent in both texts.
Personal References: Both paragraphs include first-person references ("me," "I"), and there is a consistent narrative voice that suggests a single author. The mention of personal limitations (e.g., "beyond my skill level") and self-deprecating humor ("I knew this data was available... but it's beyond my skill level to retrieve it ") is similar in both.
Technical Knowledge: The depth of technical knowledge and familiarity with Keyboard Maestro is consistent across both paragraphs. The discussion of specific features and potential enhancements indicates a shared expertise or interest in the subject.
Hypothetical and Exploratory Language: Both authors frequently use hypothetical language ("let's say you're right," "this is an academic point to me") and explore different possibilities and alternatives, which is a stylistic choice that can be indicative of a single author.
Given these observations, it seems plausible that the two paragraphs were written by the same person. However, for a more accurate determination, a detailed computational analysis using stylometric techniques would be necessary, comparing features such as n-gram frequencies, lexical richness, and syntactic patterns across both texts.
As previously mentioned, you can set the default text to n:. I use an asynchronous submacro to move the cursor to the right, to save having to do so manually.
