This post probably won't help. (I've had words with my editing staff😉.)
For my part, I may have lost the thread of the discussion, which I take it starts from the wish to have more control over the list that TBN (Trigger By Name) shows before it displays.
I'm likely missing something--since underestimating KM or the ingenuity and resourcefulness of its many adept practitioners is a common error--but I think the thing that we're running up against is the limits of using Search Strings for this goal.
The sense of scope of "app:" search string seems related to KM's use of "availability", which, I think, refers to inclusion + exclusion . So:
This won't matter if you don't have any macro groups that exclude the front app.
But if you do, app:Finder is going to match those too.
We will see macros that we want to see in the Finder plus those we don't want to see in the Finder. (app:-Finder , for my groups, seems to match nothing.)
Also...
and...
TBN's pre-filtering is really, really nice.
With All/Active/Enabled, we can filter the source list before it displays.
Search Strings further prunes that list by fields.
For multi-category searches, TBN can use Smart Group with multiple Search Strings as input. However, the main use of the Smart Group is for searches in the Editor and the Editor Suite contains its scripting commands. So if we set a Smart Group's Search Strings via AppleScript the Editor needs to be involved and would open.
To me, it seems that with @megira 's criteria what we are having trouble avoiding is resorting to the xml interface of the action.
So...
then
then
The TBN action as on-the-fly KM xml would bring TBN closer to Prompt With List's acceptance of a variable as input, making input more customizable.
Apple's many query operators include a MATCHES keyword for regex filtering for any property plus any key.
On the fly id input in TBN is super simple since it accepts ids of smart groups, macro groups and macros equally.
Wonderfully, need not worry adding Active or Enabled to our queries since we can set TBN to filter our list of ids after inputting them.
All this might bring the goal of more customized initial TBN macro name lists closer.
How I limit which macros are listed by “macro by name”
With a perspective on this issue of limiting TBN's initial list, @kevinb says:
If you don't care about such things, you have the right priorities in life...
Yep.
KM mainly tilts the effort/reward balance towards high reward low effort.
Justifying accessing KM functionality from its least tractable side, raw xml (literally no interface), may well not be worth the effort.
Yet, xml access is indeed an available KM feature after we have tried accessing its functionality via its GUI or AppleScript.
Apple's Obj-C plist query toolset, built on the same conventions as AppleScript queries, is verbose, can compound the effort costs of using KM xml and can often be avoided.
Still, it constitutes a fit interface between the user and shallow-nested, raw KM xml.