Slender-discussion

I'll respond or integrate the comments put here into the proposal. To make new comments, just copy the updated Slender page and paste it below (within ----).

This is the initial batch of comments (mainly) by Simon & AndrewFyfe.

Line breaks are honoured and whitespace can be created. The (:linebreaks:) syntax is removed and replaced with a service page that'll convert your text to the required format. A pre (or likewise named) class to force preformatted text using >>pre<<.

Line breaks are invisible, its too confusing for newbies trying to distinguish between wrapped lines, and genuine EOL characters, unless of course you are going to show them in the text area.

This is probably a matter of taste. I as a newbie turned this off, and haven't looked back. This pmwiki default just too many times resulted in a pagetext that was somehow formatted in a way I didn't anticipate. I had to go back into an edit-cycle just to get it right. I also find it creates the need for syntax to *undo* line-joining, like the end-of-line \\ syntax.

IMHO there needs to be explicit markup for line break and for new paragraph.

How did you come to this conclusion?

\ (line-join), \\ (line-break), \\\ (more line-breaks) etc at the end of a line syntax is removed. Is a replacement required?
Who uses [[<<]] and why?

It is used to break across entire page, for images and floating items. Much needed. Also need the equivalent for clear left and clear right.

This has now resulted in suggestions on the list, so it was worth it. And I'll use it too! One suggestion: 3 blank lines should probably have this same effect, what do you think? Or a version of the <HR> markup (please ignore the issue of left and right versions).

Text indented with spaces no longer generates preformatted text. Indented text connects to previous indents like lists or explicit indents where possible, otherwise indents as TABs would.

Agreed, should be explicit, eg %pre%

The standard link-format changes to use only dots (i.e. no Group/Page 'cut' syntax). Only the last part after the dot is used as the linktext if none is provided. No text extraction mechanism like [[(Big)Wiki]] is supported. This change frees up the / operator in page links.

could live with this, since you can be explicit about it, viz [[Group.Big wiki|wiki]], but looses some wikiness

Link-suffixes won't work.

can't live without this

Let's see how the final link syntax works out :-)

No support at all for wikiwords. You can do it better yourself.
Spaces are possible in pagenames. Write # instead. To get a # write ##. Pagenames are defined on creation.

interesting implications for the page store, leading and trailing spaces?

You're over complicating matters, keep life simple use a space, then for the page file name and urls urlencode the space to %20. -- AndrewFyfe

Point taken, removed from proposal /jm

An option (on by default) forces pagenames to begin with an uppercase. This allows special groups like GroupHeader to differentiate themselves.
The [[Group.Page | text]] syntax changes to [Group.Page | text]. [[Page]] changes to [.Page]. This is a shortcut for [page=Page] [[Group/]] changes to [Group.] This is a shortcut for [group=Page]

now you are adding stuff that is not required. Allow to [[Page]]], better not to allow [[Group]]

Point taken. You may be wrong for symmetry reasons if the [|Page] format is found acceptable.

You're over complicating what is already a easy to understand (and fairly standard across most wikis) syntax. -- AndrewFyfe

You may be considering the past of wikis, I hope to somehow prepare for the future (working with data, hierarchies, facets etc) and only hope to get it right.

Header syntax changes to use a single ! to indicate a normal H3 sized header. Smaller headers and bigger headers use !> (header indent) and <! (header outdent) respectively.

Sorry, not wiki

Sorry about that. I like the single !, it's clean, stimulates the use of ! (always) and I believe the semantics are better. I've updated the proposal text to reflect confusion on this point /jm

This only allows for 3 heading levels. It is also more confusing than the current syntax. -- AndrewFyfe

Not entirely: ! (H3), !> (H4), !>> (H5), !>>> (H6).

GroupHeader, GroupFooter and GroupAttributes (and others!) are no longer are part of the group, but groups by themselves, preferably within another group. Only @advanced users will see them. Maybe the [Group::header] syntax can be supported instead.
The PmWiki and Site groups, including full PmWiki syntax enabled for just these groups

What, two (2) different (confusing) mark ups!

Agreed. A farm may enable syntaxes on specific wikis. Likewise if syntax is selectable on the group level, users can be presented a lighter syntax while the backend can be a more robust standard pmwiki, also allowing recipies to be used unchanged. Updated accordingly this on the page /jm

Homepages are in the HomePage.HomePage and the group is suppressed in skins.
A Slender group contains the Slender documentation
A SlenderConfig group containing pages that affect site operation (the former Site group).

What continues as usual?

Pages are in groups and authuser controls access
* and # lists
>>div<< syntax

and (:div:) ?

The jury is out on that, any suggestions?

WikiStyles?
Too much to name here :-)

Unresolved issues

What to do with regular inline markup (@@ ''' '+ [-, etc) that can give source text such an ugly face?

some sort of styles perhaps, but nothing substantially wrong with it. It should be possible to use the same markup/style in both a span (%%) and a div (>><<).

This syntax gets ugly (real ugly in my opinion) only while applying multiple effects at the same time.

If at all possible: remove the [=...=] syntax from being used often. Reinforce use of (:markup:) and the invisible stop (like [==] in PmWiki) at strategic locations: `. (could be ?). Alternate markup needed and perhaps a strategy that instead of hiding the markup something to make it used more. /jm
Simple skin by default

Discussion:

I like the power of expression, and would be reluctant to loose it, or we end up in a morass of bland sameness. Now if we had a better skinning mechanism that we could just select and go with ...

are we still favouring authors, or administrators, or ...

IMO your approaching this concept from the wrong direction. There is no need to create a new wiki, this can easily be solved by setting $EnableStdMarkup = 0 then include your own version of scripts/stdmarkup.php

I changed the introduction to reflect your doubt that Slender would not be some pmwiki.