Is the "Execute Macro action" what "or by script" means? (I really don't know. I know what all the other script options are, but the "or by script" option has always been a mystery to me.)
No, itâs the action:
The âby scriptâ belongs to the triggers that are disabled/enabled with the check box. (See the indentation as highlighted in the screenshot in my last post.)
Edit 2019-08-19:
Since the thread has been split and disconnected from the above referenced post, here the mentioned screenshot again:
(Originally here.)
Sure. And I have no idea what that means. It "belongs to them", but what does it mean? What does "Triggered... by script" mean? How do you trigger this macro "by script"? What "script" is being talked about? It's not an AppleScript. I have no idea what kind of script is being alluded to.
Have you ever opened this popup?
This means, it belongs to the triggers thar are affected by the check box. That is: if the check box is selected, the trigger works. If not, the trigger doesnât work.
Yes. And I understand all of them, except the first one. I understand every kind of script in that list. But the first one doesn't explain what kind of script. It's the only one that lacks a description. That's why I don't understand it. What is it?
The first one (âOr by script.â) can not be opened. It is just the heading of this popup menu. The other entries can be opened and they give you a code snippet (in the respective language) that allows you to run this specific macro from within a script (AppleScript, JavaScript, Python, whatever).
Oh! It does nothing! It's just a "label"! That explains it! It's a functionless label! Thanks!
Yep, I think âlabelâ is the correct wording, thanks.
Thanks. I truly did not know it was a functionless label. I actually thought it was an option that did something (enabled/disabled something) that I didn't understand. But now it's obvious. Thanks.
Now, go on and try one of the script triggers. Itâs easy:
For example open the Apple Script item, copy the snippet into a new AppleScript (in Script Editor or Script Debugger), then run the script.
The AppleScript should now have run your macro. (The one from where you copied the snippet.)
I've used some of those before. I understand them. The only thing I didn't understand was the label thing. Now you have cleared up one of the most enduring mysteries of KM that I never understood, thanks.
1 Like
Yes, the punctuation is a bit misleading. Instead of âOr by script.â I would have written âOr by script:â. And then for the individual languages âBy AppleScriptâŚâ, âBy JavaScriptâŚâ, etc.
PS:
Note that English is a foreign language to me. So, it is possible that my perception of the punctuation is affected by the punctuation rules/habits in my language.
Understood. No worry.
Upon reflection, I don't think I like how KM manages this issue. Ie, a macro is either disabled by all scripts or by none. All at the same time. That seems so inflexible. And to make matters worse, you can't disable it at all if it's called by an Execute Macro action.
I would prefer that the phrase "> Or by script" be replaced by "Choose activation methods >" and then a list of checkboxes for each of the eight different activation methods. That makes them all independent, INCLUDING a ninth checkbox for "by Execute Macro action". But then you still need a text box for each one giving me the code required for each type of script. There could be a little triangle/arrow beside each one that lets you expand it to get the text.
It is disabled for all script triggers, if the check box isnât selected. (If not, then it is clearly a bug.)
Thatâs why I perceive it as much more clearer now. With KM8 you always had to guess:
- Can a disabled macro be run via script? [correct answer, IIRC: no]
- Can a disabled macro be run via an Execute Macro action? [correct answer: yes]
Now (with KM9) it is clear that only the triggers in the macro header (e.g. Hotkey, script triggers, âŚ) are affected by the âdisableâ check box. Not an execution via Execute Macro.
The fact that an execution via Execute Macro is not disabled can be very useful, for example when you have a macro group with a dedicated palette, and you want only some macros appear in the palette. (The enabled trigger/launcher macros, but not the disabled âhelperâ macros; the helper macros might be executed from within one of the trigger macros.)
That would be an option â as long as this deactivation is separated from the âglobalâ deactivation. (Though I think it isnât needed.)
This wouldnât work because a hotkey trigger for example is also an âactivation methodâ, no?
I donât understand this. You get the code snippet by selecting the script language from the menu:
Thatâs why I proposed an ellipsis (instead of â:â) for the script-language menu items. From the Apple Style Guide:
ellipsis A set of three dots indicating a continuation [âŚ]
And from the Human Interface Guidelines:
Use an ellipsis whenever choosing a menu item requires additional input from the user. The ellipsis character (âŚ) means a dialog or separate window will open and prompt the user for additional information or to make a choice.
(Well, in a strict sense, no additional user input is required here â except pressing âC, but the user can make the choice to copy or not to copy the snippet. And itâs a continuation in any case.)
But these are clearly first world problems 
Since I'm not at all clear if you understand my viewpoint, I've created a couple of fake images to illustrate my idea:
Then when you click on the PLUS sign you see this:
Plus a ninth box for "Execute Macro Action" which I forgot to add above.
In my mind this would be more in keeping with KM's theme of absolute power and flexibility.
You said that this wouldn't work because a HotKey trigger is also an activation method. You don't seem to understand that I'm not changing the Trigger section at all. I'm just creating a new section below it. hopefully my new images illustrate exactly what I'm thinking.
Also, instead of a colon at the end of each script type, there would be a little triangle to allow you to get the sample code that's visible in a different way now.
I think I got you perfectly fine.
I just said, the âINCLUDING a ninth checkbox for "by Execute Macro actionââ would be a more or less reasonable option. But not introducing a check box for each script language (sorry for not being explicit). Why would you want that?
I understood that you spoke about renaming the script-triggers section. Thatâs why I said this will not work (semantically), because a hotkey trigger is also an âactivation methodâ.
Oops, you got me on an inconsistency there. I'm embarrassed. Well, KM's not likely to ever change in this regard so I don't really need to fix my inconsistency.