| 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 75 added 12 lines |
| Radomir, |
|
| I agree with your comments: |
| * the use of triple braces for preformatted text complicates the MediaWiki parser, but it is possible |
| * writing templates is already a specialized skill |
|
| I've changed the collision to a partial collision. |
|
| -- MartinBudden, 2007-01-01 |
|
| Discussion on escaping moved to [Talk.AddNoWikiEscapeProposal] |
|
| At line 77 changed one line |
| Preformatted text is important for me, and is turning out to be quite tricky for a variety of reasons. |
| I note that the current draft has support for preformatted (monospace and unformatted) text, but not simply unformatted text. One of the cleanup items I need to do for [[Ghestalt]] markup is to back out my current C-like backslash syntax for escaping wiki metacharacters and implement the double-backslash linebreak. I'll miss the loss of a mechanism to implement unformatted text containing metacharacters. I find we've used the backslash quite a bit. |
| At line 79 changed one line |
| 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. |
| One possibility I'm considering (maybe as an extension) is to adapt the exclamation prefix traditionally used for making CamelCase words nowiki. In Creole style, I'd adapt that to a double exclamation point. It needs to occur at the beginning of a word (delimited by whitespace) to be interpreted. Its scope would be to the end of the word (again delimited by whitespace), and would suppress all interpretation of metacharacters within that scope. |
| At line 81 changed one line |
| 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. |
| So, for example, if you want double backslash instead of linebreak, you could write {{{!!\\}}}. And to write markup that will produce that display, you'd write {{{!!!!\\}}}. |
| At line 83 changed one line |
| 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). |
| Of course I'm allowed to do this in the spirit of ExtensibleByOmission, but I'm wondering if there's sense this kind of functionality would be generally useful, either as a proposal for the core, or possibly as a "gently suggested" extension. |
| At line 85 changed one line |
| Third, I'm currently using backslash to escape wiki markup (something often done with a <nowiki> tag). This will conflict with the proposed {{\}}{{\}} 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. |
| P.S. I want to take this opportunity to rant against the word "nowiki". I see it used here primarily as a synonym for preformatted (i.e. unformatted and monospaced), but its original usage was to defeat automatic link pattern detection, without the accompanying switch to monospace font. Thus, it seems nearly impossible to use the term without creating potential confusion about which is meant. I recommend we try to consistently use the terms "monospaced" and "unformatted" to refer to the components, and "preformatted" to refer to the combination. |
| At line 87 changed one line |
| -- [Raph Levien] 31 Dec 2006 |
| -- [[Raph Levien]] 2002-02-10 |
| At line 89 changed one line |
| 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} ~}}}}}}. The extra space does look weird, but hopefully doesn't have a meaning in math language. The second solution, if the wiki site you use talks about math often, would be to intorudce an additional {{{$$...$$}}} markup (not part of the Creole, but Creole is extensible) for math, that would either use Latex or MathML for formatting, or just typeset the mathematical formulas with a distinct font (and of course escape the markup). |
| I used "nowiki" to mean "unformatted, not monospaced text". Personally, I'd like to see {{{{{{foo}}}}}} in this role, and then {{{##foo##}}} as the "unformatted, monospaced" text in Creole Extended. In the absence of that markup, {{{{{{foo}}}}}} can produce monospaced text, if it's desirable on particular wiki. This is not as important for inline markup -- you can't line up characters anyways, because you don't know the line length. So changing the font from monospace to normal or the other way around is not going to mess things. |
| At line 91 changed one line |
| Second, obviously no markup should be interpreted inside "nowiki", except the three closing curly braces, and maybe an escape character, if we will have any. Of course, markup defined outside of the "nowiki" span, like lists, emphasis and tables, is still in effect. |
| There are several reasons why I'm advocating "#" for marking up inline monospaced text: |
| At line 93 changed one line |
| Third, we still don't know what markup to use for the line ends. We are open to suggestions. "\\" is just one common solution, but I'm sure we can do better than that. |
| * it's the most popular markup that is acceptable in Creole [[http://www.wikimatrix.org/syntax.php?i=26|listed at wikimatrix]], |
| * it's used mostly for variables, snippets of code, etc. -- great number of programming languages use "#" as a comment character, and comments are unlikely to appear in these snippets, |
| * it mirrors the markup used for bold, so we can use all the same rules and techniques used for lists/bold, |
| * it has no other obvious use, |
| * it looks good (to me). |
| At line 95 changed one line |
| Thank you for your feedback, and please remember that Creole is supposed to be a "common part" of wiki markups (or an alternate input method), not necessarily the only markup available -- there are so many different use cases, that this woudn't be possible. |
| What do you think? |
| At line 97 changed one line |
| Btw, your idea with the closing curly braces is interesting -- I don't think it breaks anything, and it lets you write {{{{{{{{{...~}}}~}}}}}} without the need for escape characters or spaces -- I doubt anybody would need a "nowiki" span immediatelly followed by a curly brace. |
| -- RadomirDopieralski, 2007-02-10 |
| At line 99 changed one line |
| -- RadomirDopieralski, 2006-01-01 |
| I don't understand very well what it adds wrt corrent "nowiki". Nowiki now serves for monospaced sequences, and it leaves the content unparsed, which I think is correct and desirable. Mixing monospace and other markup... I'm not sure. |
|
| The only "problem" is when you want to escape some markup, for example introducing a sequence of asterisks in text, without producing monospaced output. But for this purpose an [[Escape Character]] is more appropriate, IMO. It'd be necessary, anyway. Now that we're using "\" for forced linebreaks, we could use it as an escape char as well. |
|
| -- [[Michele Tomaiuolo]], 2007-02-11 |
|
| 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 |
.