Talk:Macro commands
Namespace
Many of these already have names in the mainspace that could use expansion, rather than second pages. Ie, Friend (keep it there please!). May want to have a look and then change the links on this page to match. --Sky (t · c · w) 23:54, 31 December 2008 (UTC)
- The Friend page deals specifically with the generalized term Friend, what it means, etc... What I'm creating is pages dealing with the command /friend. All of the macro commands here are grouped together in a format like the WoW API, and I intend to add this to the Holy Writ section of the UI portal. The distinction is clear enough between Friend and /friend, and the format of the Macro API pages needs to be standardized. I would not mind putting links to these commands on pages that exist, but creating the Macro API is enough work as it is, and I don't really feel the need to go hunt down all of these commands to place links on pages that already exist in a more general sense. --DrDoom (talk) 21:37, 1 January 2009 (UTC)
Thank you so much for making this! -Cowlinator (talk) 23:32, 16 January 2009 (UTC)
Conditionals
I removed this section as it does not pertain to all macros. Some macros already have the conditionals included (see MACRO cast. If you would like to improve that part, maybe a better way would be to make that section a link to another page that you can click on via the argument list, then you can add it to all of the macros for which conditionals work. You could add a subsection regarding conditionals, or maybe just as a note at the bottom, and link to it, but make sure it is specified that not all macros support conditionals. Only certain macros will process these. Thanks for wanting to make this a better place, but we just need to keep it in a manner that keeps things clear and concise to everyone. If you have any questions about adding major information, please post here for group discussion. --DrDoom (talk) 00:34, 17 January 2009 (UTC)
- Ok, thanks for the help. I have no idea which commands conditionals work for so I guess I'll just leave it alone. -Cowlinator (talk) 01:20, 17 January 2009 (UTC)
Page Title
I suppose some people find the title "Macro API" to be inappropriate for this section, and I see it has already been renamed on the main UI portal page. Here are the reasons why I chose to name it as an API rather than just "commands":
- It follows the same page format as API pages
- These commands are literally functions, and deserve to be treated as such. They are passed arguments and each one performs a specific task, just like the LUA functions. The fact that they are called via the command line or a Macro shouldn't have any bearing on this.
- API stands for Application Programming Interface, and Macro Commands are sometimes a necessary part of scripting, as there are things you can do in a macro command that is not possible (in combat) with LUA scripting.
- There are a million iterations of "Macro Commands" pages out there, many of them being on wowwiki as well. I wanted to make sure that anyone viewing it realized that this should be one of the first places to look to see correct syntax and usage of any macro commands they intend to use. EDIT: To clarify, I mean to distinguish it from a Guide page, as it is not intended to be a guide to instruct people on how to do various tasks; only to list syntax and functionality.
I am open to discussion on the issue. --DrDoom (talk) 11:06, 14 April 2009 (UTC)
Music Player Commands
I noticed that the Music Player Commands section is empty with red links. I'm planning on testing the commands and playing with them a bit, and will come back with the results (Patch 3.1.0 is taking forever to download). I'm not planning on making pages for said commands, but I will if need be. --DJ 1337 Man (talk) 23:28, 14 April 2009 (UTC)
- Hey thanks for the help, but after reviewing the output again with the 3.1.0 data, I discovered that these were not commands, but instead arguments to the /stopwatch command. The global variables start with SLASH_ like all other commands, but the value is not preceded by a "/". Its a little odd to me but hey it works for them I suppose. That section has been removed and the /stopwatch command updated. --DrDoom (talk) 11:39, 15 April 2009 (UTC)
Merge with List of slash commands?
Since someone suggested we merge this with slash commands and did not post anything here, I guess I'll start it up. I don't see much difference in the two, save for the page referred to is pretty incomplete and out of date. I will add the emotes to this page, though, and I vote that the other page be set up to redirect to or reference this page. --DrDoom (talk) 23:35, June 3, 2010 (UTC)
- This makes sense to me. All slash commands redirects to the referenced page as well. I'd say there's quite a bit of overlap on Slash commands that could be cleaned up as well. Two thirds of that page are just categorized emotes. Elviswind (talk) 01:26, June 22, 2010 (UTC)
- I don't see why we would want to clean up Slash commands, personally. This page presents slash commands in a much clearer format, and has detailed description pages for the inner workings of every command. I think the other pages should redirect here, as this format is more conducive to presenting the information people want. --DrDoom (talk) 00:22, 21 October 2010 (UTC)
MACRO links and normal links
Some of the commands point to MACRO pages, and others to "normal" pages. For example: Say points to MACRO say but Yell points just to Yell. Why is that distinction? I would make Yell point to MACRO yell. Hans Kamp (talk) 05:53, 25 November 2011 (UTC)
- The page format was originally modeled after the API pages, which all began with an API prefix to make a distinction between common terms and the library reference, and I followed suit when I created this. For example, the "friend" page contained information about what a friend was, while the "MACRO_friend" page contained information about the macro command and its command line usage. People have been working periodically to merge this information to make it easier for people to find information. I personally have been extremely busy IRL, so I haven't been proactive in helping with it, except to make sure new command references from the environment are updated. --DrDoom (talk) 17:31, 25 November 2011 (UTC)
Substitution sequences
I added this section as a subsection of Chat commands (well, actually moved it from UI escape sequences). It slightly breaks the uniformity of the listings but seems appropriate since those patterns only work in chat. I also wouldn't be opposed if someone wanted to make it its own page, as Foxlit suggested elsewhere. - jerodast (talk) 22:42, 20 August 2014 (UTC)
csay entry as the primary for "Send chat to channel #" is incorrect. The primary is /#.
The primary for this command, per the /chat help command in-game is /#. /csay and /c are listed as aliases for that command.
Altering that, however, involves more than just changing the name of the command. It involves adding a new page. I'll be putting a note in the csay discussion page as well about this.
We're getting beyond my depth on edits to wiki pages with this.Mltco78dhs (talk) 22:44, 18 August 2017 (UTC)
- Adding a new page is rather easy. You can read this for help! Xporc (talk) 09:38, 19 August 2017 (UTC)
This page needs a major overhaul
There are issues that need to be addressed about this page beyond fiddling with the details.
1) There needs to be a meeting of the minds on terminology. This page: https://wow.gamepedia.com/Making_a_macro gives two conflicting sets of terms to describe the elements of a macro command line. The page under discussion (Macro API) deviates from both of those. The more technical EBNF syntax diagram, while incomplete is nevertheless accurate as far as what it does include and says a command is "/" and the character string that follows (terminated by a space, newline, or end of file) is a "verb". The "syntax diagram" a little earlier on that same page says that "/verb" is a command. The Macro API page says that the EBNF verb, minus the slash is the command. We need to pick one and then propagate that terminology throughout the entire universe of gamepedia macro api references.
2) There needs to be a meeting of the minds on whether these are going to be represented in the wiki pages as "MACRO verb", "verb", or something else. Given that what are being described here are Blizzard-supported slash commands, rather than "macro commands" (except for the two metacommands), I would prefer to see this whole thing altered to reflect that and use the format "SLASH verb" or "SLASHCOMMAND verb" instead. Many of these behave differently when executed from a macro than they do when executed from the command line ("/2" executed from the command line changes the default output chat channel to channel 2 (if it is not already that). "/2" executed from a macro does not.) I think it might be a good idea, as we work though the list of "commands" to rework them into a topic naming scheme of SLASH verb. That is more accurate, reflects the dual nature of what is being explained, and implies (correctly) the link between Blizzard's slash command interface and the one used by add-ons.
3) In the linked articles, we really need to find a way to standardize terminology. "Player" is used to mean "player character", in many, many instances. I realize that Blizzard refers to the class of player characters using the Unit Type of "player" but outside of the context of Units, that term is ambiguous. I've seen the term "optionset" used as if there is a single definition of that. In some instances, optionset means the full range of targeting and conditional choices. In others, it is limited to only conditional choices. I would like to see about developing a standard set of words that mean those things. To distinguish between the full set and the no-targeting set, for instance, I think "optionset" (for the full set), "conditionset" (for situations where targeting is not allowed), and "specialoptionset" (for situations where neither the full nor condition only sets are entirely accurate representations of what can be used) are good choices. The icon file id index needs a standard name. We need to do what we can to make the variable names in our interface descriptions match what Blizzard uses (an example is that in almost all cases, Blizzard uses spellID in the FrameXML\*.* files, but spellId is used more often in these pages). I get that camelcase is a thing and that it has passionate supporters, but ID is the accepted abbreviation for "identification" with "Id" being a poor second choice as it represents an actual word and Blizzard's own code (the code we're supposed to be documenting) shows a strong preference for ID over Id. That may sound trivial, but if you haven't spent a day hunting down an error in code you copied from the Blizzard API only to find that code you copied from this site changed the casing of variable names, you can't know how frustrating deviating from canonical usage is.
4) There are distractions on this page that need to be moved out to another. The list of substitution strings, for example, should probably be linked rather than explicitly shown on the page. More likely, it should simply be removed. We don't need information about socks on a page about shoes. If a page needs to be created to discuss the possibilities of and shortcuts for composing chat messages beyond just text, create one and link it to the chat category page (see below about that).
5) The segregation of the commands into categories provides a layer of information, impedes easy visual searching for individual commands. A better way to do this would be to tabulate the list of commands, present them alphabetically, and add a columns to the table for which category the command fits in (or categories, if more than one - /g (chat in the guild channel) fits in with guild functions as well as it does with chat functions, for example), what synonyms exist for each command, and a notes column for those situations where even at the summary level, a note is required. If the reader needs to see the commands grouped by category, we add a page link to the category name itself that provides a brief description of that category and list of links to the individual commands from there. We list every variation of every command and emote individually without concerning ourselves with whether something is the alias or the primary (Blizzard's systems don't care, we shouldn't). Tabular form, with an unabridged command (including emotes) listing, a category column, a synonyms column, and a notes column would cover all the bases, especially if it is possible to put a user-sortable table on the page (the "real" wikipedia has this option - I don't know if we do here).
6) A reference to FrameXML\GlobalStrings.lua with (perhaps) code for extracting the canonical slash commands would be useful for addon-developers and macro developers alike. That file does not (strangely) contain absolutely every possible slash command in the game, but it does contain the vast majority of them and clear links between synonymous (aliased) commands. From that list, I think we should also agree that the version of the command under the EMOTE#_CMD1 or SLASH_COMMANDDESCRIPTOR1 value is the primary command name and all others are aliases of that (if we bother with designating a primary at all - I'll get to that).
7) I dislike the term "alias". Using that term in this context is somewhere between imprecise and incorrect. A more suitable term for the varying canonical forms of a command that all mean the exact same thing is "synonym". "Alias" in data processing generally means a programmer-defined, non-canonical name used to bring a variable or function into local scope or simplify code appearance. That is not what these are. These are literally different terms canonically-defined at exactly the same level of scope to mean the exact same thing with the exact same system impact at run-time. To put it in personal terms, parents naming a child Robert understand that they've also named him Bob, Bobby, Rob, Robbie, and Bert. Those names are synonyms (strictly speaking, diminutives) of Robert. If Robert later fills out a request for a clearance for a government job, he does not have to list Bob, Bobby, Rob, Robbie, or Bert as aliases because they're not. If Robert, however, spent some time working professionally under than name Randolph, for whatever reason, that would have to be reported as an alias. The distinction is a fine one, but significant in the context of a technical document describing usage of an API in a programming environment. Switching from alias to synonym has the advantage of not weighting one form over another. In each table entry and each detailed page, if there are synonyms, list them. If not, don't.
8) We need to develop strict standards for use of jargon words like focus and target. To be frank, I haven't quite settled on a proposal for this. If "object" weren't both an emote verb and an already-established data-processing term, I would suggest that, but it's already double-used now. As an example, when an article about /focus says it "sets the focus target", that is just a jumble of imprecision. What the /focus command does is puts the character's current target into the character's current focus. The character's focus target is the target of the unit in the character's focus. Because of situations like that, we need a term to replace "target" in the original setting. I guess the best might be unit. "/focus sets the characters focused unit" isn't perfect, but it's far, far less ambiguous than the existing phrasing. I'm sure the community can come up with a standard for this sort of usage that will work, but what is happening now is a mishmash of mixed meanings for terms that is confusing as heck. Updating this one entry to say that I've found the canonical usage that is probably what should be adopted site-wide here. It's "focus unit". Focus target can mean the target of your focus (and does, quite often in the various discussion boards), the focus of your target (by folks who are precision-reading-impaired or misunderstand the lexicon of the macro api), or it can mean the unit for which UnitExists("focus") returns true. Primarily because of that latter example, I believe that all references to "focus target" that do not mean "focustarget" should changed to "focus unit" wiki-wide for the sake of precision, technical accuracy, and consistency with Blizzard's identification of "units."Mltco78dhs (talk) 18:06, 19 April 2018 (UTC)
I'm sure the community might want to add to the agenda of this discussion. Please feel free to. I suspect it may be a lengthy process to work out the solutions to each of the points I raised and to those yet to be raised by the community as well. I just think it's time to get that discussion going.Mltco78dhs (talk) 13:58, 22 August 2017 (UTC)