Neil Harris wrote:
> In the spirit of supplying concrete examples, here are my proposed
> changes to the syntax of the existing language:
>
> * the existing {{{parm}}} or {{{parm|default}}} notation should be
> changed to ${parm} or ${parm|default}
>
I'm not sure that would actually be parsed. And I'm no fan of leading $,
left over from the variety in PERL.
PHP isn't a model syntax that we should employ.
Actually, as the triple brace syntax is older than the parser functions,
I've never found them to be a problem. And since whitespace is already
compressed (to nothing) in the argument portion of parser functions,
I've never had a problem with adding some whitespace; that is:
{{#if: {{{1|}}}
|
|
}}
My recent surprise was the elimination of leading and trailing *newlines*
in the "then" and "else" portions, apparently only in subst'd templates,
behaving *differently* than transclusion. See my thread:
"subst'ing #if parser functions loses line breaks, and other oddities"
That thread spawned these later discussions.
> * all newlines and other multiple whitespace characters within template
> source code should be regarded as reduced to single spaces, with
> explicit calls to {{newline}} and {{whitespace}} operators to generate
> explicit whitespace on output
>
Since they are already reduced to nothing, that's a given.
I do like the idea of explicit functions {{#line:}} and {{#space:}}, with
parameters indicating the number (that is, {{#line:2}} and {{#space:2}}).
Or {{LINE:}} and {{SPACE:}} or {{LINES:}} and {{SPACES:}} or ....
This would compliment existing magic words {{padleft:}} and {{padright:}}.
> These two changes alone would greatly increase the readability of
> templates, both by massively reducing the number of curly brackets
> within templates, and by allowing them to be formatted in a clearly
> nested and indented form.
>
> If I could add one more change, it would be an {{apply}} function, to
> allow explicit calls to other templates whose names have themselves been
> generated by template substitution, as used extensively in templates
> such as {{coord}}; this would help clean up the semantics of the
> underlying language a bit more, allowing further changes to be made more
> easily both to the syntax and implementation, and also possibly allowing
> a faster implementation that does not require SNOBOL-like re-parsing of
> generated text.
>
Didn't the new parser fix that problem? Besides, SNOBOL was nifty... Once
upon a time, I was proficient. (Now, I'm not sure I remember the syntax
some 30 years later.)
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
