On 11/20/07, Mark Clements gmane@kennel17.co.uk wrote:
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).
Put like that, it's a compelling argument: those three terms are very descriptive.
links, so the term 'automatic links' might be better, and again removes a bit of the mystery.
Yep. It could possibly be even better, but I'm not sure how. "Implicit link"? "Bracketless link"? Dunno. I hate them anyway. :) ("Evil bracketless link"?...hmm)
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.
Some of them really behave like variables in a template, but with two braces instead of 3. "Template" really implies a calculation of some kind to me. But either is ok.
Can "built-in variables" take arguments, and if so, how are they treated?
This is resolved if we refer to them as "built-in templates" instead.
So, they can take arguments, and the syntax is with a pipe like a normal template. So what is {{DEFAULTSORT:foo}}?
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.
No, it uses a colon. It just happens that Wikipedia has a template called {{DEFAULTSORT}} which calls {{DEFAULTSORT:{{{1}}}}}. *groan*
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.
Well, the page name is the default sort key anyway. But, yes. __FOO|Arg|Arg__ looks ok to me. Would <nowiki> work, if you need to pass in a __ somewhere?
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}}.
Hmm...well, we're not supposed to be changing anything at all at the moment. Perhaps we could at least set up a list of all the magic words at the moment, set up a proposed syntax change, and how they would all map, and see what it looks like. Of course we could implement the change in the current parser, to avoid the restriction on changing syntax and parser at the same time :)
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.
That's a problem. I was originally asking about "anything being a magic word" because if anything can be, then parsing is harder. Changing to a more uniform structure but supporting the old terms doesn't help much. Though in practice I don't think it will prove to be a huge problem.
Steve
On Wed, Nov 21, 2007 at 02:26:00PM +1100, Steve Bennett wrote:
Yep. It could possibly be even better, but I'm not sure how. "Implicit link"? "Bracketless link"? Dunno. I hate them anyway. :) ("Evil bracketless link"?...hmm)
For what it's worth, I have seen application config files with parameters like
ONLY_IDIOTS_WOULD_ENABLE_BRACKETLESS_LINKS
:-)
Cheers, -- jra
wikitext-l@lists.wikimedia.org