However, __TOC__ is of the latter type, but the former syntax. Well, in fact, it's of both types. It's a directive not to include the TOC in the normal position, and to include it in a different position. It's difficult to draw a clean line between the two types of magic word.

On 11/16/07, Mark Clements <gmane(a)kennel17.co.uk> wrote: They're the same thing in the implementation. Magic words get to return values, set flags, or do whatever else they want.

"Steve Bennett" <stevagewp(a)gmail.com> wrote in message news:b8ceeef70711161637g3d660294o6ba60df237a64e83@mail.gmail.com... Actually, no. Thomas Dalton replied to my e-mail saying that __TOC__ was actually a variable, but in my reply I stated (for the same reasons you give) that it is a parser directive. [SNIP] I think it's very important to drop the use of the word 'magic' in describing these types of things. There is nothing magic about syntax-based substitution. 'Magic' words in MediaWiki are "ISBN", "RFC", unquoted URLs, etc. These are plain-text elements that are automatically turned into links, whether the user wanted that or not, and which do not require any extra syntax. The special tokens that are surrounded by two underscores are 'parser directives' and the special tokens that are reserved words surrounded by double curly braces are 'built-in variables'. There is nothing magic about them (unless we also want to call text surrounded by two square brackets 'magic links' and lines with equals signs at each end 'magic headers'). - Mark Clements (HappyDog)

"Jay R. Ashworth" <jra(a)baylink.com> wrote in message news:20071119185958.GB392@cgi.jachomes.com... syntax-based URLs, That's my point. Things like ISBN, RFC, etc. are magic words. Things like __NOTOC__ and {{PAGENAME}} are no more magic than [[Link]], and so shouldn't be described as such. - Mark Clements (HappyDog)

The thing that makes them magic words is that they are *words* (or, at least, acronyms). "[[" is just punctuation. Even though they require particular punctuation to work, they are still words that have some extra purpose beyond just being text - we call that "magic".

"Jay R. Ashworth": That may be so, and if so, this is probably the historical reason. However, based on various comments made on this list and elsewhere, I think that the lack of distinction between the different purposes, syntaxes and behaviours is causing confusion, so regardless of the historical reasons they should be clearly differentiated. This doesn't imply any code changes, of course. Simply a change in nomenclature when documenting or talking about wikitext and the parser. "Jim Hu": And the docs have been written by developers who call them magic words for the reasons above. This name is not helpful to users, and in fact I believe it could be harmful. The more 'mystical' we make the parser, the more daunting it is. Just because we have called them magic words in the past, doesn't mean we should continue to do so if the effect is detrimental. "Thomas Dalton": Nope. I don't agree. There is no magic. Magic is when something happens without you doing anything, such as for ISBN numbers. Perhaps the issue here is that you are describing the siutation as it has historically been, and I am describing the situation as I think it should be. If we change the paradigm so that instead of "__TOC__ is a magic word" we say "TOC is a parser-directive; parser directives are enclosed in double underscores" then things become a lot easier, and general cases can be made. In your example above TOC would be a word, and __ would be the 'punctuation'. Contrary to what you say, the word has no meaning without the 'punctuation' (same as link text). Add the 'punctuation' and you add an extra meaning (same as link text). Here is how I would formalise things: Parser directives: * Anything enclosed in double-underscore is a parser directive. * A parser directive tells the parser to do something (or not to do something) that affects the rendering of the article. * Unrecognised parser directives are ignored and output as normal text. * Recognised parser directives are: TOC, NOTOC, etc. Built-in Variables: * Built-in variables are enclosed in double curly braces. * Unrecognised variable names are ignored and are treated as template inclusions. * Recognised variable names are: PAGENAME, BASENAME, etc. - Mark Clements (HappyDog)

"Steve Bennett" <stevagewp(a)gmail.com> wrote in message news:b8ceeef70711191926j3722bcb9obfe6c5b1487253f5@mail.gmail.com... No {{PAGENAME}} would not be. This would be referred to as a built-in variable (though see below). Really, this isn't really about logic in that sense, it's about changing the way refer to things. Part of this is to make a logical distinction between the 3 different entities that have a different syntax and a different purpose (parser directives, built-in variables and automatic links). We should not be using the word 'magic' for any of these constructs. At most, the word magic could be used to refer to things that modify straight text without any extra user syntax (e.g. ISBN, RFC, in-line html links, etc.) but as far as I know this kind of construct is only used to create links, so the term 'automatic links' might be better, and again removes a bit of the mystery. [skipping ahead a bit...] Yes. It occurred to me, shortly after writing that post, that they should not be referred to as "built-in variables", but rather as "built-in templates". That is the term I shall use from now on. This is resolved if we refer to them as "built-in templates" instead. [Skipping back to an important point] Hmmm.... well here you've found an exception (and there may be others). DEFAULTSORT is a parser directive, but it uses the template-style syntax. This is partly a symptom of the problem I am describing (lack of a formal definition of these items) but is also probably down to the fact that the __ syntax doesn't support arguments as easily (though I don't see why not). We need to think about how to resolve this e.g. can we re-define DEFAULTSORT: __DEFAULTSORT|Sort key__ seems plausible. __DEFAULTSORT|{{PAGENAME}}__ seems a little, well, odd... but maybe that's just because it's new. Or do we change the syntax to remove all double-underscore directives, and change them all to use template syntax? In this case parser-directives could be distinguished by being prefixed with an underscore (e.g. {{_NOTOC}}). Or we could make them into built-in parser functions {{#NOTOC}}. These last ideas are just off the top of my head mind, and need further consideration. Any syntax changes would of course need to retain existing functionality (as 'deprecated' syntax) to preserve backwards compatability. Well, if there were no exceptions to the definitions then no changes would be necessary, as it is just a matter of nomenclature. The exceptions need a bit more thought - it would be good to identify them all so we can see what we're dealing with here. - Mark Clements (HappyDog)