Wikimark2/Old

Wiki functions

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

\ (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

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

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

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

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

>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

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