Right now, it only includes "enabled" macros, but I have full control over what's returned, because I generate the list in JXA. So I can add whatever options we want.
Click for image of macro
I added the option to use a regular expression to either filter out, or only include macros whose names match the regex. Right now, I set it to filter out my palette separator macros.
Could your macro be adapted to do something similar?
I noticed it's not quite as snappy as the native action. This is me being really nitpicky, but do you think it might be better to grab the macro list (as a global variable) whenever the KM Editor is closed? I know that would mean that you wouldn't be able to trigger a brand new macro until you closed the Editor, but it would probably mean your macro would run quicker in day-to-day use.
Thank you, that's very interesting and I'll study the macro for my education.
Sure... Please note that I am not asking for refinements to be implemented, and this is just by way of requested feedback.
Advantages over the built-in action:
The panel is indeed gone. (Since no-one has corrected me about it being impossible to remove in the standard action, I shall post a suggestion about this elsewhere).
Disadvantages at present, compared to the KM action:
As you mention, currently the macro lacks fine tuning of which macros are included.
The macros are not listed.
Leading numbers (used for setting the order) are not hidden, e.g. a macro called "3)Do something" will not appear as "Do something".
But yes, it works smoothly and is a good proof of concept.
I wouldn't, no, but thanks again and I look forward to studying the macro.
I have now found a post from @peternlewis from October 2023:
"There is no way to affect the appearance of the palette."
Sorry to have returned to something that had previously been covered. I did search but perhaps "macro" being spelled as "makro" in the title hid the thread from me... Well, it made a change from "marco"! I've corrected the title in order to, I hope, make that thread more findable for others.
No worries from me. I've posted on plenty of topics I posted on previously and totally forgot, so I can't criticize anyone else for their lack of searching ability!
For whatever weird reason, my brain can handle that in some situations, but not others. So I've an Outlook Conflict Palette with n as the distinguisher for my Inbox window, d for the team's calendar window, and so on.
But I guess I think of apps and bookmarks by name, and it's less mental load to type outl or bofh than to "translate" the thing I want to a "shortcode".
Ain't that the joy of KM? You can go your own way...
I'm too focused on hunting and pecking the keyboard to notice that
That's totally true, and also, I was just this minute listening to "Go Your Own Way" by Fleetwood Mac.
Yeah, me too. And I've gotten worse at it with old age. Have you ever stared at the keyboard and wondered where a certain key went? "Where the hell is the $ key?"
Agreed, but try looking for £ or hash sign on the wrong type of keyboard.....
PS Just for the old-timers here...
Ascii and Extended Ascii was fine until IBM invented EBCDIC when you got zero, positive zero and negative zero together with a different sort sequence for letters and numbers
Zero in ebcdic
In EBCDIC (Extended Binary Coded Decimal Interchange Code), the character for zero is represented differently depending on its sign.
Positive zero: 0000 or 000 (without the curly braces) denote a positive zero.
Negative zero: 000{ (with a curly brace) denotes a negative zero.
When packing decimal numbers in EBCDIC, the left nibble of the last character is often overlayed with 0xF to make it a readable EBCDIC character digit, resulting in the zoned decimal format.
I recently had built this for myself using applescript and pulling the macro list from specific folders I want to generate a list to filter/choose from. So this might accomplish more of what you want.
It does give a list of the macros by default this way without needing to type.
You can list as many folders as you want in the within the 'set macroGroupName' area.
tell application "Keyboard Maestro"
-- List of macro group names
set macroGroupNames to {"GROUP1", "GROUP2"}
-- Create the lists
set macroNames to ""
set nameToUUID to ""
-- Loop through each macro group
repeat with macroGroupName in macroGroupNames
set macroGroup to macro group macroGroupName
set macroList to macros of macroGroup
-- Loop through each macro in the group
repeat with aMacro in macroList
set macroName to name of aMacro
set macroID to id of aMacro
set macroNames to macroNames & macroName & linefeed
set nameToUUID to nameToUUID & macroName & "||" & macroID & linefeed
end repeat
end repeat
-- Trim the trailing newline
if length of macroNames > 0 then
set macroNames to text 1 thru -2 of macroNames
end if
if length of nameToUUID > 0 then
set nameToUUID to text 1 thru -2 of nameToUUID
end if
-- Set the Keyboard Maestro variables
tell application "Keyboard Maestro Engine"
setvariable "MacroNames" to macroNames
setvariable "NameToUUID" to nameToUUID
end tell
end tell
Thank you, very interesting. For me, that method has pros and cons compared to using the conflict palette, which I shall weigh up carefully... It's certainly a convincing option.
What's the search string for the app-specific group here? Does its contents somehow change based on the front app, or are you just making a group for a specific app like Logic?
I find it a shame you need to press → to type without deleting the initial string. I wish that was an option.
If you always want to append, rather than overtype -- write a "Keystroke: →" macro that has a 0.1s pause before typing →, then call that macro asynchronously just before you pop the search:
Peter is following Apple's "Human Interface Guidelines" -- pre-populated dialogs should have their contents selected ready for the user to replace. It may not even be an option to do otherwise in standard dialogs. So "the meantime" could be "a very long time", hence the workround.
If it's synchronous then it must complete before the "Trigger Macro by Name" action is executed -- the keystroke will be before the prompt is up. And you can't do it after the "Trigger Macro by Name" action because the prompt blocks execution. So you fire it off before, asynchronously and with a slight delay, so the keystroke happens after the dialog appears (but before the user gets bored of waiting!).
That makes sense, though I do understand the frustration of the few threads I've seen on this behaviour. Another workaround is to do a Prompt with List or use a launcher like Alfred, but neither of these give you the macro's icon.
