Wikimark2/Old

From Meta, a Wikimedia project coordination wiki

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**