Wikimark2/Old
Wiki functions
[edit]As is evident, the syntax is <<function input>>. The function name has no space before it. If there is a space, or the parser cannot find a function for the function-name given, then the text between the <<>> tags becomes nowiki'd by default. Hence:
<< unparsed text >> <<foo unparsed text >>
Escape
[edit]\ (backslash), like in many languages, is an escape character. Placed before any of the above code-types ({{}}, [[]], <<>>), it forces the parser to ignore it.
"<<code <<nowiki Look here \>\>\>\>\> at me! >> >>"
The above would give: "Look here >>>>> at me!". If the backslashes were not there it could give: "Look here > at me! >> >>"
This can be used as a shortcut to a simple use of <<nowiki {{spoiler}}>>. Instead one can just write: \{{spoiler\}}.
Paragraphs
[edit]Paragraph Paragraph with This line not broken Paragraph
However, not many users realize this initially. Thus the parser automatically detects line-break errors. If a line ends with punctuation, the parser infers a line-break:
Paragraph.
Paragraph.
This line breaks, as previous line ended with "." (full-stop);
Any line ending with , ; . " ' ! ? % ) breaks (<br />)
Paraphraph
This line does not break
Paragraph.
Paragraph; no line-break at end of previous, as
followed by empty line, not more text.
Paragraph
Possible table errors
[edit]The closing and ending of a table means that the following table could break earlier than desired:
!! 1:1 !! woooah, this cell has some serious space! end of cell - closing tags --------------> !! !! row2 !! cell2 !!
The above table may - depending on how clever the parser is, break after the first cell, and hence be only 1 cell large. This is because a table ends when there is a pipe followed by an empty line. Arguably this is not a problem. Whenever does one need empty space at the top of a cell? If it is desperately needed, then the above error can be avoided:
!! 1:1 !!
{{}}
woooah, this cell has some serious space!
end of cell - closing tags --------------> !!
!! row2 !! cell2 !!
Table wiki function
[edit]A table's extension can be made explicit by encompassing it in the (new) wiki function <<table>>. This is also useful when line-breaks might break up a function of larger scope, or when table parameters might be accidentally parsed as part of a larger functions parameters. So:
<<table !! 1:1 !! 1:2 !! 1:3 !! cell 1:4 lalala! closing tag --------------> !! !! 2:1 !! 2:2 !! 2:3 !! 1:4 !! >>
generates an explicitly contained 4x2 table. As with normal syntax, any linebreaks can be reduced to <<br>> to write a multiline string on one line. This also applies to the table syntax. New rows can be specified by replacing each newline with <<br>>. This allows a table to be written in a continuous string, which makes it much easier to include within a template. So:
<<table !! 1:1 !! 1:2 !! 1:3 !! <<br>> !! 2:1 !! 2:2 !! 2:3 !! >>
would give a 3x2 table. Note how the above string can be easily part of a template's parameters. Although it is now not so intuitive, templates never are, and are often more complicated anyway.
Table attributes
[edit]Attributes have aliases. Simply including the alias in the right place assigns that attribute. So for instance, one could simply write "right" instead of "align=right". The "header" alias performs the same function as exclamations used to do in Wikimarkup. See further down for a full list of aliases.
Individual row control takes place after the row in question (after closing tags):
!right! 1:1 !! 1:2 !! 1:3 !! header !! 2:1 !! 2:2 !! 2:3 !! class=foo !! 3:1 !! 3:2 !! 3:3 !! style="x: y"
Entire table control involves a fake first row, with no closing tags:
!! border=1 !! 1:1 !! 1:2 !! 1:3 !! !! 2:1 !! 2:2 !! 2:3 !! !! 3:1 !! 3:2 !! 3:3 !!
Indentation
[edit]>indented text >>twice indented text <indented in opposite direction, once <<again, right-side indent, twice ><block quotation <>block quotation
The last line of the above would generate text indented like this paragraph ("block-quoting"). The last line of the above would generate text indented like this paragraph ("block-quoting"). The last line of the above would generate text indented like this paragraph ("block-quoting"). The last line of the above would generate text indented like this paragraph ("block-quoting"). The last line of the above would generate text indented like this paragraph ("block-quoting"). The last line of the above would generate text indented like this paragraph ("block-quoting"). The last line of the above would generate text indented like this paragraph ("block-quoting").
The order of <'s and >'s is unstrict and irrelevent; the parser just counts the number of left and right brackets at the beginning of a line and indents as appropriate.
Possible bolding errors
[edit]Closing tags are strictly not optional - this avoids ** interfering with unordered list markup. Tags are non-greedy and evaluated from the right. So the following code would give the example on the right:
- bbbbbbbb
bbbbbbbb
- bbbbbbbb
bbbbbb
bb**bbbb
**bb**bb**bb**bb** **bb**bb**bb**bb **bb**bbbb**bb **bb**bb**bb** bb**bb**bb**
This demonstrates error-control. However, it is not normal for any length of text to contain so many double-asterisks; in 99% of cases you will be able to mix unordered list and bold markup without any problems. For instance, the following normal code gives the (intuitively desired) result on the right.
- Point 1
Bold
***Point 1** **Bold**