Loading...
 
Development

Development


Development model for wiki syntax parser?

posts: 13 Denmark

Apologies for originally posting this in the wrong forum (features/usability):

I realise I am new here, so although I have looked around a little for an answer in vain, this question might have been asked before:

What is the development model for the wiki syntax parser?
What I mean is, what is the consensus/decision-making pattern for making changes to the wiki syntax?

Each change has of course the risk of breaking pages on existing sites — and is of course breaking Rule#3...

While I find the concept of plugins as a way of optional extension very good, I do find there is some very basic stuff that should be considered for inclusion in basic wiki syntax.

Three examples come to mind:

  1. Text alignment. Right now we can do default alignment and centering. Why not opposite alignment (that's right alignment for English), left alignment, right alignment and justified alignment? This seems inconsistent.
  2. Linking to anchors within wiki pages. (Tiki)Wiki is inherently about linking, so it seems odd that such a basic feature of HTML is not integrated into basic wiki syntax.
  3. Table syntax can produce only very rudimentary tables, with hardly any support for column alignment or merging.

Now, I realise that these features are provided by (probably several) plugins, but the extensive syntax for plugins makes wiki less usable for novices, due to the many brackets in the wiki source text. And these features just seem SO basic (to me, at least).

I haven't followed the historical development of TikiWiki wiki syntax, so I cannot tell what the Right Thing To Do is, and it has also been mentioned that someone is developing a new version of the parser. But if I was to suggest extensions to the wiki parser for the first three issues above, I could think of

    • :o:...text...:/o: for opposite alignment
    • :r:...text...:/r: for right alignment
    • :l:...text...:/l: for left alignment
    • :j:...text...:/j: for justified alignment
  1. ( (WikiPageName#AnchorName) ) for links, and o+)(AnchorName) starting at the first column for anchors
  2. Someone (I forget who) suggested doing table cell alignment according to whether the source text had spaces after the first bar (right alignment), before the last bar (left alignment), both (centered alignment) or none (justified alignment). At least on the face of it, this seems smart.


— Arne

posts: 2881 United Kingdom

You can already do 1, 2 and 3

There is a recent forum topic for table formatting and alignment is dont with the div syntax.

In 1.10 which is the latest development tiki there is a pluginable syntax parser. Its the same one thats used currently in TikiPro/BitWeaver, so if you want this function now, give BitWeaver a try: http://www.bitweaver.org

Damian
http://free.tiki.at.tikihost.net

posts: 13 Denmark

Thanks for the info, Damian! smile

> You can already do 1, 2 and 3
>
> There is a recent forum topic for table formatting and alignment is dont with the div syntax.

I think I might have expressed myself less than sufficiently clearly. My point was development of basic wiki syntax, the 1--3 character codes, not the lengthy brace-name-parenthesis-brace-brace-name-brace plugin syntax.

So doing it with div syntax is in this perspective not a solution. The solution is to devise a minimal set of codes for wiki text that a large part of the users can agree is in sufficiently frequent use to be called basic. In this quest, it would seem to me to be sensible to consider consistency (cf. alignment: including all values of some dimension from which you include a value), frequently used web features (cf. linking to anchors within pages), and avoiding source text blowup for simple, often repeated constructs (cf. cell text formatting within tables).

> In 1.10 which is the latest development tiki there is a pluginable syntax parser. Its the same one thats used currently in TikiPro/BitWeaver, so if you want this function now, give BitWeaver a try: http://www.bitweaver.org

Unfortunately, I did not succeed within 15 minutes of surfing that site (even after registering and doing a test page edit) to find any description of this wonderful parser.sad

Finally, I notice that my main question has not been commented or answered by anyone yet: What is the development decision process like for the wiki syntax?
Put slightly differently, is the basic wiki syntax freezed forever, relegating all and any useful and sensible future enhancements to a non-default-enabled plugin or modification?

Respectfully,

— Arne

posts: 2881 United Kingdom

> Finally, I notice that my main question has not been commented or answered by anyone yet: What is the development decision process like for the wiki syntax?
> Put slightly differently, is the basic wiki syntax freezed forever, relegating all and any useful and sensible future enhancements to a non-default-enabled plugin or modification?


No rules can change there current role, if new characters pop up and are liked by the majority then they can make it into the main wiki parser. But again I stress that no rules can change there meaning.

Damian
http://free.tiki.at.tikihost.net


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting