Old discussion moved to [Talk.Versions].
----

Please write your opinions of Creole 0.1 here.  --[Chuck Smith]

I think nested lists were not agreed upon. They should go.
I also think that the section about preformatted text is ambiguous. It does not differentiate between preformatted and unprocessed, and yet it says that it will work in-line and as a block. But what is preformatted + inline supposed to mean? Clearly whitespace cannot be significant in-line! (One reason being that you cannot nest a pre element inside a p element!)

Which is why Janne & I suggested that triple braces as a block will produce preformatted and unprocessed text (pre element, no processing), where as triple braces inline will produce unprocessed text (span element, no processing).

I think the only other alternative that makes sense is that triple braces inline will produce monospaced & unprocessed text (code or tt element, no processing).

-- AlexSchroeder

We did indeed agree on nested lists about an hour and a half into the workshop and no one opposed them.  Nested lists are __very__ useful and we think they should stay.

You are correct about in-line and pre.  I made some changes.  Does the current state of pre on Creole 0.1 satisfy you?

-- [ChuckSmith]

If I understand correctly, we now must detect the raw URLs in text and mark them up, right? Good thing there is a ready [regular expression for url|http://foad.org/~abigail/Perl/url3.regex].  But it adds a lot of complexity.

-- [RadomirDopieralski], 2006-09-06

How does detecting raw URLs add so much complexity?  I mean, even Ward's wiki did it since the beginning from what I remember...  --[ChuckSmith]

It is complex if you want to be correct at all times. Most software just uses some kind of heuristics -- sometimes better, sometimes worse. As the exact solution is rather out of our reach, maybe we should just leave it up to the developers?

Right now I use a simple algorithm: Anything that starts with a protocl name (from a short list) and a colon is treated as url, up to but not including, a space or a punctuation character (like comma or full stop) followed by a space. Or end of line, of course.

But this is not 100% in accordance with the specification, is it?

-- [RadomirDopieralski], 2006-09-06

I think that's fine.  --[ChuckSmith], 2006-09-06

I'm happy with the preformatted stuff. Thanks!

As for nested lists, I'd like to stick to what [Lists] starts with: "Only one level lists are supported in v0.1 (i.e. no sublevels and no mixed unordered and ordered lists)." -- AlexSchroeder

Oops, I have deleted that now.  I meant to erase that before, because multi-level lists were decided upon at WikiSym with no opposition.  Well, except for you opposing it now.  I also noticed that nested lists even work already on Oddmuse, so I don't really see what the problem is.  If you know anyone else who also does not want multi-level lists, we could consider changing it, but all wikis that I know support multi-level lists, so it seems to be a basic feature.  --[ChuckSmith]

Well, Oddmuse only does one particular kind of list; the leading whitespace issue and the use of the dash required new rules on top of the existing ones. Plus mixing bullet and numbered lists raises the kinds of issues that Radomir talked about. Plus nesting could also happen with indentation. MoinMoin uses indentation, and as I said, my plain text files also use indentation, if they use nested lists at all. I also find them to be bad style except for (automatically generated) table of contents information. That's why I don't think it is something to be added lightly to a recommendation. But since it was decided at the workshop, I won't raise the issue again. Sorry for raising it now, in fact. The text on [Lists] led me astray. -- AlexSchroeder