What would textual analysis show if we compared the posts of Airy, Sleepy and DocOck?
Inquiring minds want to know.
Can I downvote this post? 
I’m aware that some ingenious macros relating to Prompt with list have been contributed to the forum. If I were that unhappy with using my macro that is based on Trigger macro by name, I would investigate those further, but as it happens, I am very happy with the macro, and it’s simply that… see posts above.
Already I don’t like it. 
My take (with arguments that may or may not seem relevant from the perspective of your own aims and needs!) is that, even allowing for “muscle memory”, when using more than one trigger there must be a degree of distraction while one considers which category the macro is in before pressing the corresponding shortcut keys. My method is aimed at matching against only macros that I have already decided should be available from that UI element—that’s its entire point—and since everything has been arranged in advance, I can use just one trigger and be confident that irrelevant macros will not be matched against.
Yes, as previously mentioned by, for instance, me, in the first post of this topic, in which I also explained why that is not satisfactory:
I note with interest that you went with a subroutine solution rather than an Applescript one such as that discussed above:
… or maybe it wouldn’t, then. 
Fair enough, thanks for your input. So there are still no “for” votes! Although I find it less than ideal that Trigger macro by name insists on matching against contents too, I can deal with any macros that are matched by content by editing their contents (I would rather do that then have n:s clutter up the interface) and such problems won’t, in any case, happen often because, remember, I only ever see in the prompt those macros that have been marked to be allowed to appear there and which are currently active; the issue is simply that, among those “eligible” macros, I should prefer not to see any irrelevant results when I start typing characters against macro names… Indeed, I wonder who ever would want to trigger a macro by matching against its contents, but… oh well! That’s how it is, and, it seems, how it must remain!
Thanks to everyone for the replies. I think by now the answer to my simple question has become clear: no-one else would like to see the behaviour of Trigger macro by name made tweakable. I can live with that!
Hey, that’s Docsing! 
@noisneil For your “App-Specific” Smart Group, is that one group that varies with the frontmost app? How do you set that up?
I'm struggling to find reference to it. Did you describe or even post it somewhere?
Yes, exactly. In my case, I mostly want to see macros available to the current app. If I want anything else, I use a modifier. I could of course use a completely different hotkey, but I'm used to this now.
I agree that it wouldn't take much to add a "match by macro name only" option to the action's gear menu, which would sidestep slightly clunky workarounds that don't feel intuitive for new users.
Agreed! Perhaps, in fact, contents-matched results should be disabled by default and optionally enabled via the gear menu?
Yes, exactly:
I also have a hotkey that shows me different lists of available macros depending on what kind of file/folder is selected in Finder:
If I hit ` in Finder, it runs a macro that determines the file-type and then presents a list of macros to trigger, based on the corresponding Smart Group.
I have a Group specifically for these file-specific macros. As an example, you'll see a bunch of them named with the Logic - prefix.
My Finder - Logic Smart Group is set up like so:
If a Logic Pro project file is selected, it will conditionally show the macros matched by the Smart Group filters:
I hid it (it seems!) in the footnote attached to “a macro that I use frequently” in the first post. I’m sorry it was hard to find; I had been trying to add a convenient link to that post without highlighting it, because my was to get responses about other people’s use of the Trigger Macro by Name rather than to provoke a discussion about that macro. That didn’t entirely pan out, but that’s what I had been going for.
Sure. I didn’t mean to imply criticism of your workflow but I felt that adding a disclaimer to that effect would be a distraction! I wrote of course entirely from my own experience, and that was that if I had more than one trigger for the same interface element, I had to stop to think rather than instinctively hit a key combination. Using a modifier key is an interesting take but sometimes I have to pause to think whether I need to press ⌘-space for Alfred or ⌃-space for that macro-trigger macro of mine, so even there, it might be better if I were to combine the two!
I wouldn’t dare assert that anything would be “easy to implement” in KM, but you’re a forum leader and hopefully can get away with it. 
Perhaps that could be tricky to implement while maintaining backwards compatibility with existing user macros? Someone might once have wanted to match on contents…
Good point, well made!
As was I -- or rather, in this case, from the perspective of a user who was given (or downloaded) the macro and could reasonably expect the scope to be set to relevant Groups.
Thinking further -- the number users who a) understand Group scoping, b) know about search strings, c) would get confused by the different UX experiences, but d) don't know to check an Action's settings is vanishingly small.
I withdraw my objection. And its exclamation point (I'm sure I'll find a use for it later...).
On the syntax:
It shouldn't be, if you're ever going to type more than one word into the prompt. Should those words appear in the name in any order and maybe with other words between (n:dummy n:macro) or as a phrase (n:"dummy macro").
I think maybe the first, since the behaviour carries over from things like web search engines so people know to quote phrases.
I look forward to it!
Perhaps we are at cross-purposes, or perhaps I have missed a point here. I wrote:
But again, this is an academic point to me. Rather than fiddling with search syntax, a
Trigger Macro by Nameaction that strictly triggers a macro by name (and not contents) is what I have in mind
In other words: we don’t currently have to worry about the default matching style in Trigger Macro by Name, and I don’t want to have to concern myself wth it in any implementation of Trigger Macro by Name Really Just Do That. I would just like the action to stop matching on contents.
Mine is actually a sub-macro, except it's executed on the fly from the AS code rather than being saved in KM. Partly so I don't have yet another little sub saved in the Editor, partly because I could , mainly because I found I had to wait for the dialog to appear or the → would get lost elsewhere and since that required AS I might as well send the arrow key from there too.
Ah, so it’s a macro that is called from another macro, but it’s not a subroutine.
(If I remember correctly: although the wiki uses the phrase “sub-macro” once or twice, I don’t think it is defined.)
May I just quickly emphasise have to and default. I hope the meaning is clear.
I probably would too, if I had enough macros! Fortunately, while I use the Action dozens of times a day, it's always scoped tightly enough so that the "name" I type is never in the contents of another macro.
Then you probably want n:"dummy macro" so that typing dummy m would select the "Dummy Macro" macro and not the "Macro with Dummy Actions" one.
"Sub-macro" is probably the closest. Strictly speaking you might say it wasn't, since it isn't directly called by the "parent" macro -- you could run that script manually in Script Editor to the same effect -- but the AS Action that (asynchronously) runs the script that tells KME to execute the (transient) macro defined by that XML is in the parent, so I think it falls within the loose definition of "a macro executed by another macro".
I think the closest the Wiki gets to a definition is the mention on the %TriggerValue% page.
Very good point!
Lest it feel like I'm banging on about something insignificant, @kevinb, my thinking is along the lines of...
Why not rename the Action "Trigger Macro by..." and allow presets for all the things, in a manner similar to the "Format" option in the "Calculation" Action? So your Action would be
...but you could equally set the Action to
...and so on.
These would allow only a single qualifier, and the "unformatted" default would be as it is now with as many (or no) qualifiers as the user wants to type.
What I want is to be able to use something called Trigger macro by *name* in a macro, type foo and then not see in the list of macros a macro that has foo in it in a comment, an if action, a while condition, switch/case, group name, append variable with text, display text, press a button, open a url, cut to named clipboard, semaphore lock, flip image, write to a file… 
One overlong Monty Python sketch later… 
or anywhere that isn’t part of the name of the macro.
I asked if anyone else would like it to be possible to limit Trigger macro by name to just macro names but we have seen by now that there is no demand. I accept that, and I have said that I can work around it.
Breathes into paper bag I mean, thanks, though.
Blunt opinion: the wiki should not casually drop in jargon that it does not define. Putting something in quotes is a cop-out.
@noisneil Thank you. When I set up the App-Specific Smart Group as you did, it indeed displays the macros for the frontmost app that are in groups available in that app only, which is exactly as expected. It also displays the macros that are in groups that are globally available except in one or more excluded apps (assuming the frontmost app is not one of the excluded ones), which is also as I would expect. However, it does not display macros that are in groups that are “available in all applications”, which I don’t understand. Why doesn’t is display macros from groups that are available in all apps, but does display macros from groups that are “available in all apps except …”? I can deal with that by simply specifying an app that is never relevant for KM purposes, but I’m just curious as to the logic of why the search works that way.
yes, me too. I just wondered why excluding an app (other than the front one) made a macro group show up in the list, but “all apps” doesn’t. A picture is worth a thousand words, so here goes:
This macro runs the Smart Group “App-specific” search defined as you showed earlier in this thread:
but, when run in an app, doesn’t show the macros in this group:
BUT, if I change the ALL - GENERAL group by excluding an app like this:
THEN, I do see all the macros in ALL - GENERAL when running the “Smart grpp” (TriggerMacroByName) macro in any app (other than Fantastical, of course).
That puzzles me. Not your problem, obviously, just wondering if anyone knows why.