Because I wanted to get PasWiki up and running as fast as possible (instead of continuing to write all my notes in my looseleaf binders and on other people's web forums or other people's wiki's) the syntax of PasWiki was not immediately decided.
Web programs evolve and should not be decided upon from day one.
Here are some ideas I've had over the past year while PasWiki has been running as-is:
Extensible Syntax
I'm not fond of XML - it is hard to read, ugly, over-hyped, microsofted, and obfuscated. No one wants to write a wiki in XML. However, having a wiki syntax that is extensible is an idea, such as this:
He was going bold(to the store) to get tomatoes and he italics(loved) the cashier
who worked at the store.
Instead of using regular curled brackets like the above, they could be replaced with square brackets. The advantage of using a functional markup language (functional because it's like lisp, returning something that is enclosed in brackets) is that it can be extended with time.
However, it would probably be best to shorten the above verbose syntax to something like:
He was going to the i(store) to get tomatoes and he obviously b(loved) the
cashier.
Functions like big() small() b() i() could be added in the beginning stages to the parser fairly easily. But what if we wanted to extend the wiki to offer more features? This extensible functional language would be much cleaner than the oh ugly XML, would be cleaner than the oh ugly HTML, and would be cleaner than many other extensible languages. The reason I think square brackets should be used instead of Lisp style curled brackets is because in English writing we often use brackets frequently. I don't want to have to escape brackets each time I need to write a curled bracket. And I don't want to have to enclose all my text in quotations if I need to escape curled brackets. Rather, why not just use square brackets since square brackets are rarely used in English literature/essays/notes?
For bullets, unordered lists, ordered lists.. there are a few options of syntax
Bullets(
this is point 1;
this is point 2;
this is point 3; )
or
Bullets(
:this is point 1
:this is point 2
:this is point 3 )
or
Bullets(
* this is the text in point 1
* well this is the text that is inside point 2
* and this is point 3 of course )
Bullets(
:this is point 1
:this is point 2
:this is point 3)
In order to distinguish from an ordered list and an unordered list, there are again several ways of going about it. The simplest would be markup functions:
bullets(), orderlist(), uorderlist().
(replace all curled brackets with square brackets)
How about Tables for comparison purposes in the wiki?
Table(
row(
:this is some text in cell 1
:some more text but in cell 2 )
row(
:some text in cell 1 of row number 2
:text in cell 2 of row 2 )
)
Or...
Table(
row(
* this is some text in cell 1
* some more text but in cell 2 )
row(
* some text in cell 1 of row number 2
* text in cell 2 of row 2 )
)
(replace all curled brackets with square brackets)
Problems with using semicolon or colon as delimiter are that we use it in English literature so this is not a good choice. Quoting the text would get rid of that problem but quoting is a pain in the neck and more useful in a programming language than an essay markup language.
A possible solution is to use a keyboard character that people rarely ever use in English literature, such as Mr. Squiggly:
Table(
row(
~ this is some text in cell 1
~ some more text but in cell 2 )
row(
~ some text in cell 1 of row number 2
~ text in cell 2 of row 2 )
)
Bullets(
~ this is point 1
~ this one is point 2
~ and this is point 3 )
(replace all curled brackets with square brackets)
Another possible solution is to use doubled up colons, something people rarely use in literature:
Table(
row(
:: this is some text in cell 1
:: some more text but in cell 2 )
row(
:: some text in cell 1 of row number 2
:: text in cell 2 of row 2 )
)
Bullets(
:: this is point 1
:: this one is point 2
:: and this is point 3 )
(replace all curled brackets with square brackets)
How about bullets underneath bullets? i.e. stair-cased bullets or hierarchical bullets..
Bullets(
~ this is point 1
~ ~ this is a reply to point 1
~ ~ ~ and this a reply to the above point )
Or since people rarely use the pipe character in English:
Bullets(
| this is point 1
|| this is a reply to point 1
||| and this a reply to the above point )
How about properties? HTML/XML has properties within a tag. Let's take the table and add some properties to it:
Table( \bgcolor: red; font-face: courier;\
row(
:: this is some text in cell 1
:: some more text but in cell 2 )
row(
:: some text in cell 1 of row number 2
:: text in cell 2 of row 2 )
)
Table( \bgcolor: red; font-face: courier;\
row(
| this is some text in cell 1
| some more text but in cell 2 )
row(
| some text in cell 1 of row number 2
| text in cell 2 of row 2 )
)
Or:
Table( |bgcolor: red; font-face: courier;|
row(
~ this is some text in cell 1
~ some more text but in cell 2 )
row(
~ some text in cell 1 of row number 2
~ text in cell 2 of row 2 )
)
Or
Table( ~ bgcolor: red; font-face: courier; ~
row(
:: ~ bgcolor: gray; font-color: green ~
this is some text in cell 1
:: some more text but in cell 2 )
row(
:: some text in cell 1 of row number 2
:: text in cell 2 of row 2 )
)
Or cell() can enclose text and properties
Table( ~ bgcolor: red; font-face: courier; ~
row(
cell( ~ bgcolor: gray; font-color: green ~
this is some text in cell 1 )
cell( some more text but in cell 2 )
)
row(
cell(some text in cell 1 of row number 2)
cell(text in cell 2 of row 2 )
)
)
Or back to the pipe character with cell() enclosing cell text
Table( | bgcolor: red; font-face: courier; |
row(
cell( | bgcolor: gray; font-color: green |
this is some text in cell 1 )
cell( some more text but in cell 2 )
)
row(
cell(some text in cell 1 of row number 2)
cell(text in cell 2 of row 2 )
)
)
For stair-cased (treed) bullets, the double colon gets a bit verbose,
bullets(
:: this is bullet 1
:: :: text replying to bullet 1
:: :: :: text replying to above bullet )
But it still works, and doesn't look bad at all.
Although it seems we are reinventing HTML or XML here, it is still cleaner to use in basic form. When properties are added, it looks more and more complicated and gets closer to html, but a majority of wiki pages are created with structures that don't have properties, such as an italic tag or a quick comparison table, or a code insertion.
Table(
row(
:: this is some text in cell 1
:: some more text but in cell 2 )
row(
:: some text in cell 1 of row number 2
:: text in cell 2 of row 2 )
Versus
{table}
{tr}
{td}this is some text in cell 1 {/td}
{td}some more text but in cell 2 {/td}
{/tr}
{tr}
{td}some text in cell 1 of row number 2{/td}
{td}text in cell 2 of row 2 {/td}
{/tr}
{/table}
When a row is created, we know there most likely are going to be cells inside that row. We don't need to necessarily mark up the text as cell() as that gets in the way of the editing. We can replace cell() with a double colon :: .
When an ordered or unordered list is created, we know there are going to list items inside. We don't necessarily need to mark up each and every list item as listitem() or li(). We can just use double colon since we are sure there should be list items inside. However, if a list item (bullet) is to be customized, the double colon syntax does not offer tag properties like html does. This is fine, then the author of the wiki article can resort to using Cell() in those situations with properties.
Another syntax to consider:
TABLE(
----
:: | bgcolor: gray. font-color: green. |
this is a cell with properties
:: a cell with no properties
----
:: a cell with no properties, row is parsed in here fine
:: cell with no properties,
)
How to do a box? A div box with a dashed line
BOX( | font-color: red. border: dashed. |
this is red text inside a box with a dashed line around it )
When making notes in a wiki, usually we just need to box in some text and rarely do we need customized boxe with colored text and special borders like above, so:
BOX( this is the default box, a solid line and regular text inside )
Since many people make use of dashed boxes, we could also have
DashBOX( this is text in the default dashed box )
Since many people make use of dotted boxes, we could also have
DotBOX( this is some text in a default dotted box )
|
