Comment about macros executing "recursively" is inappropriate.
Macros cannot "recurse" at all due to Blizzard checking for what they call "circular" execution.
A better phrasing would probably be this:
In cases where multiple macros are chained using the /click command, this command stops the macro it appears in without affecting macros further into the execution chain. Mltco78dhs (talk) 22:31, 18 April 2018 (UTC)
- The comment is using recursively in a broad sense: the C implementation of RunMacro can end up running commands which in turn cause it to be called again, so there's recursion going on at that level (which shows up in stack traces). I considered "simultaneously" as an alternative, but the "in parallel" connotation would be somewhat annoying. I dislike "chain" because it, to me, suggests that the control handover between macros is final, and only happens once (i.e. macro A calls macro B at the end, which calls macro C at the end, because we couldn't fit all the stuff we wanted into macro A, and so had to split it between B and C). The real behavior is a bit richer than this: A can trigger B, then run some additional commands, and then trigger C.
- While this isn't really the point, macros can certainly recurse in the direct sense, with a macro causing itself to be executed. Try the following: create the following macro, and place it on both ActionButton1 and ActionButton2. Click ActionButton2, and notice that that what appears in the chat frame is: "Hello Hello world world". There are of course limitations here, but they stem from /click, which does nothing if a button is already in the process of being clicked.
/run print("Hello")
/click ActionButton1
/run print("world")