| At line 66 changed one line |
| * Template pages can render inline {{{{{{...}} } }}} as nowiki text by default, with two exceptions: |
| * Template pages can render inline {{{ { {{...}} } }}} as nowiki text by default, with two exceptions: |
| At line 120 added 58 lines |
|
| You can't use "\" for escape character, because you woudn't be able to put the literal "\" in text, since {{{\\}}} is taken. And yes, I was aware of that when it was introduced. |
|
| I don't think that introducing yet another new mechanism for how markup works is desirable. Right now we have basically two machanisms: parenthesis-like, for bold, italic, unformatted, links, etc., and a marker at the beginning of the line, for headings, links and tables. They are both encoutered in everyday life and easy to learn by observation. |
|
| Now, the notion of "escape character" is familiar for programmers. And that's it. It introduces a new way that markup works, makes the text hard to read and laborous to write or modify. It is also very awkward to parse using regular expressions, as you have to take it into account as a negated regexp (which are already pretty hard to write) in each and every pattern you use. Finally, I'm not aware of any wiki engine that'd use it (!NoWiki is a tad different and convoluted already). |
|
| Honestly, I can't see a situation where you really need an escape character. The {{{{{{unformatted}}}}}} text is enough, and if you need the monospaced text to be meaningful, use {{{##monospaced##}}} or {{{##{{{unformatted monospaced}}}}}}{{{##}}} and you're set. Sure, they are a little lenghty. But they **are** exceptions, so they should stick out from the text. |
|
| -- RadomirDopieralski, 2007-02-11 |
|
| I agree with Radomir, in the last paragraph: {{{##}}} should be for monospace only (//not// unformatted, i.e. like |
| all other style markup such as {{{**}}} and {{{//}}}), and {{{{{{...}}}}}} should be for preformatted text only, without any |
| style change. Completely separating the two effects makes them simpler to describe and to use. Monospace text |
| with links is useful, for instance. |
|
| -- [[YvesPiguet]], 2007-02-11 |
| ------------- |
|
| Should nowiki wrap the line or not (like jspwiki does, better for code display) or should we leave this to the implementer (I am for the later, but at least we should talk about it) |
|
| -- [[ChristophSauer]], 2007-05-05 |
|
| It's not even the implementer's decision, I'd say -- it's the decision of the designer who creates the layout for the particular site. |
|
| -- [[Radomir Dopieralski]], 2007-Apr-05 |
|
| ==== distinctions |
|
| Like [[Raph Levien]] does, I would appreciate to see clearly distinguished the notions of |
| * unformatted = raw text segment = no styling |
| * monospace = typeset style |
| (also code = source-editor-like highlighting) |
|
| //**note** : a proper (and positive) word for "unformatted" may be "litteral"// |
|
| As the three of them may be useful on segments (=span) as well as on blocks or even block sequences, I take here the opportunity to advocate for a rule that may make creole more consistent, thus easier : |
|
| //Segment styling delimiter tags (double characters at both ends) can all be used as block styling tags (simple character at line start only).// |
|
| Which leads e.g. to: |
|
| | **format** | **use / semantic** | **standard rendering / display** | |
| | {{{/ distinct block}}} | example, remark, advice, block-quote | italic (+ indented)| |
| | {{{* important block}}} | important notice | bold (+ indented)| |
| | {{{X litteral block}}} | e.g. formatting explanation | unformatted | |
| | {{{Y monospace block}}} | text graphics, ascii art... | monospace | |
| | {{{Z code block}}} | source code | highlighted | |
| etc... |
|
| In addition , this lets the possibility to combine block styling easily and in an evident manner, or even block layout and styling. For instance : |
| | {{{XY litteral & monospace block}}} | |
| | {{{#X litteral numbered list item}}} | |
|
| I find this really user-friendly. The only condition, which imo would rather be a major improvement, is that text-styling does not conflict with block-layout. (As presently for bold and bullet lists, also number lists and monospace according to Radomir's proposal above.) |
| What about that for creole 2.0 ? |
|
| [[spir]] - 15 sept 08 |
.