(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

I'd like to propose the following logic for handling this element:

  1. If the first brace is on the first column, and there are no non-whitespace characters after the last brace, then this element starts a block-level element.
  2. Otherwise, start a <span>.

The point is that I've found that my users often want to escape markup within a sentence, and the above rules seem to work well in that case.

Whether there is whitespace before the first brace is a matter of taste, I believe.

-- Janne Jalkanen, 31-Aug-2006

like this?


this is an example {{ ==h1, **bold** }} that starts a span
and this is an example as a block for sourcecode

{{
println 'hello world';
}}

This way we would not need seperate syntaxes for monospaced and preformatted

-- Christoph, 31-Aug-2006

Well, monospace is different from preformatted which is different from monowiki. But essentially, yes.

-- JanneJalkanen

I agree with Janne. I'd phrase the rules differently, however:

  1. If the opening triple braces start on the first column, open a pre block. It is closed by closing triple braces starting on the first column.
  2. Any other opening triple braces open a span. They are closed by tripple braces.

This has the benefit that you can include the markup for unprocessed text inside the markup for preformatted text. Something I have wanted to do on this wiki several times!

The desired result is:

To produce bold text, use {​{​{**bold**}​}​}.

And not:

To produce bold text, use {{{**bold**}}}.

-- AlexSchroeder

Collision with MediaWiki format parameters#

Unfortunately {{{..}}} for preformatted text collides with MediaWiki template parameters, see Creole Markup Collision Analysis. Since MediaWiki is probably the most popular wiki of all this needs to be changed.

-- MartinBudden, 2006-12-28

So a single wiki engine uses markup conflicting with Creole for a feature pretty unique for it. That's unfortunate. What can we do?

Update: After some reaserach on MediaWiki's templates, I think it's not that bad at all:

  • Normal (non-template) pages can use monospaced text without problems
  • Template pages can use the preformatted blocks normally
  • Template pages can render inline {{{...}} } }}} as nowiki text by default, with two exceptions: ** When there is only a number inside, and the page is being included as a template with at least that number of paramteres ** When there is a parameter name inside, and the page is being included as a template with that named parameter passed It has two disadvantages: * makes it harder to explain/understand the creating of templates -- but they are pretty advanced and rare feature anyways * makes it a little harder to write (and maintain) the parser -- but that's something you do for a single wiki engine -- and at its cost you have a pretty popular and collision-free syntax in Creole. It's not me who is going to do that work, but I think it's worth it. ** RadomirDopieralski, 2006-12-29 ---- Preformatted text is important for me, and is turning out to be quite tricky for a variety of reasons. First, I need to handle inline comment enclosed in curly braces (this is a common notation in set theory, like {A, B}). So if I have four open curlies followed by four closes, how do I handle that? One provisional solution I'm considering is associating the extra close curlies with the ''inside'' of the span, so the regex for the closing markup is three closing curlies not followed by a fourth: {{\}\}\}(?!\})}} in Python syntax, for the coders out there. This would also provide an escape for three or more closing curlies inside a span: just follow those with three closing curlies followed by three opening ones, to open a new span. Second, the 0.3 spec seems to indicate that wiki markup is processed inside the inline preformatted element. That would be a problem, because there's all kinds of stuff that might go in the tag, some of which might look like markup. Block elements clearly do not have their markup processed. In any case, even if no wiki markup were allowed inside preformatted inline spans, it would be possible to get the bold preformatted effect by reversing the nesting of the markup, putting the bold on the outside and the pre on the inside (as a reminder of how tricky this is, I was not able to get a sample to render correctly in this Wiki engine). Third, I'm currently using backslash to escape wiki markup (something often done with a <nowiki> tag). This will conflict with the proposed [{ImagePro src='' }][{ImagePro src='' }] syntax for linebreaks. My current inclination is to remove it entirely, but that leaves me with no good way to indicate nowiki outside monospaced spans. A workable hack is to intersperse empty preformatted spans to break up what would otherwise be interpreted as markup. -- [Raph Levien] 31 Dec 2006 For the first of your problems I can see two solutions. If it's only an occassional thing, then you can go with {{{{A,B} }}~}

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 01-Jan-2007 14:43 by RadomirDopieralski.