| 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 85 changed one line |
| !Comments about preformatted text |
| Discussion on escaping moved to [Talk.AddNoWikiEscapeProposal] |
| At line 87 changed one line |
| Preformatted text is important for me, and is turning out to be quite tricky for a variety of reasons. |
| ---- |
| At line 89 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. |
| 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 91 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. |
| 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 93 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). |
| 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 95 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. |
| 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 97 changed one line |
| -- [Raph Levien] 31 Dec 2006 |
| 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 99 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). |
| -- [[Raph Levien]] 2002-02-10 |
| At line 101 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. |
| 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 103 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. |
| There are several reasons why I'm advocating "#" for marking up inline monospaced text: |
| At line 105 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. |
| * 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 107 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. |
| What do you think? |
| At line 109 changed one line |
| -- RadomirDopieralski, 2006-01-01 |
| -- RadomirDopieralski, 2007-02-10 |
| At line 111 changed one line |
| One idea would be to extend Creole to have a [heredoc|EnWikipedia:Heredoc] style syntax. That way could vary the terminating token as needed. |
| 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. |
| At line 113 changed one line |
| -- JaredWilliams, 2006-01-01 |
| 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. |
| At line 115 changed one line |
| Isn't it a little complicated, and unfortunately, impossible to parse with regexps (ok, it's possible with perl's and python's regexp, by use of the python's {{{(?P=...)}}} for example). What's more, do we need/want to have Creole "complete", in the sense that every (valid) output is possible to achieve? |
| -- [[Michele Tomaiuolo]], 2007-02-11 |
| At line 117 changed one line |
| -- RadomirDopieralski, 2006-01-01 |
| 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. |
| At line 119 changed 2 lines |
| Its just a back reference isn't it? Something like {{{ /{{{(\w+)\n(.*)\n\1/ }}}. |
| Obviously most Wiki's probably wouldn't need such a feature, therefore probably shouldn't be in Creole. But also offers a syntax for marking a range of text (if generalised further) to assign an identifier to a section of a page for transclusion. |
| 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. |
| At line 122 changed one line |
| -- JaredWilliams, 2006-01-01 |
| 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). |
| At line 124 changed one line |
| The extra spaces in Radomir's [CheatSheet] suggest the need for extra escaping logic for three closing braces on a line by itself within a preformatted block. I suggest that one backslash is removed from any line within a preformatted block consisting entirely of one or more backslashes followed by three closing braces. This could be optional in the ExtensibleByOmission sense, to make life easier for implementors of simple Creole engines. In any case the chance of this pattern being an actual collision is near zero. Note also that this pattern is the same as the JSPWiki hosting this page, except that JSPWiki uses tilde instead of backslash. (I don't have a strong feeling about this choice, and could live with tilde) |
| 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. |
| At line 126 changed one line |
| I was curious how the main page PreformattedAndNowiki implemented the escaping, and found zero-width spaces between the closing braces. This is a rather extreme form of InvisibleMarkup. |
| -- RadomirDopieralski, 2007-02-11 |
| At line 128 changed one line |
| I have implemented the suggestion of associating extra curlies to the inside of an inline preformatted block in [Barghest], and am happy with the way it turned out. |
| 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. |
| At line 130 changed one line |
| -- RaphLevien 2007-01-02 |
| -- [[YvesPiguet]], 2007-02-11 |
| ------------- |
| At line 132 changed one line |
| Escape logic is not required for preformatted text if (a) the Creole parser reference counts the number of opening and closing braces inside the block; and (b) the block contains a balance of opening and closing braces. Of course, a) might be difficult to implement in some languages, and b) might not be possible in all cases. Anyhow, it works well for me in Key/C and generally the text I work with has a balance of opening and closing braces, so it's no problem. |
| 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) |
| At line 134 changed one line |
| I'm hoping to avoid escape sequences in my wiki implementation but perhaps at some point they will become necessary. As a point of interest, I can copy the whole [Creole 0.1 Test Cases] text into my preformatted block without making any changes. It's kind of fun and certainy a good challange for the parser! |
| -- [[ChristophSauer]], 2007-05-05 |
| At line 136 changed one line |
| For what it's worth, I think the JSPWiki use of tilde for escaping three closing braces is nice and clear. |
| 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. |
| At line 138 changed one line |
| -- MarkWharton, 2007-01-03 |
| -- [[Radomir Dopieralski]], 2007-Apr-05 |
| At line 140 changed one line |
| Counting is a possibility, and handles the CheatSheet use case fairly handily, but I think it's not as wiki-like and not quite as general (what if you wanted separate blocks to show the beginning and ending sections?) |
| ==== distinctions |
| At line 142 changed one line |
| I was going to write that because there are a couple of good ways of doing this, it's a good candidate for ExtensibleByOmission, but if the CheatSheet becomes popular, it really would be a good idea to have it work without alterations in most all Creole parsers. |
| 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) |
| At line 144 changed one line |
| -- RaphLevien 2007-01-02 |
| //**note** : a proper (and positive) word for "unformatted" may be "litteral"// |
| At line 146 changed one line |
| I'm against special cases in the spec, even if they allow some popular use cases. If we are going to have an escape character, it's best (IMHO) to make it work everywhere the same. |
| 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 : |
| At line 148 changed 15 lines |
| Why not solve the problem of three closing braces the same way |
| as in the inline nowiki blocks? If there are two (or more) consecutive lines containing only "}}}" in them, make all but the last one of them a part ofthe pre block, and treat the last one as the ending: |
| {{{ |
| {{{ |
| {{{ |
| some example |
| ~}}} |
| ~}}} |
| }}} |
| this doesn't limit the expressive power of Creole -- if someone __does__ desire to put three closing curly braces right after the pre block, he/she can separate them with a blank line (this introduces an explicit end-of-block instead of the implicit one after the <pre>) and have the expected result: |
| {{{ |
| {{{ |
| {{{ |
| some example |
| ~}}} |
| //Segment styling delimiter tags (double characters at both ends) can all be used as block styling tags (simple character at line start only).// |
| At line 164 changed 2 lines |
| ~}}} |
| }}} |
| Which leads e.g. to: |
| At line 167 changed one line |
| I don't even think it needs to be mentioned in user cheat sheets -- because that's the __expected__ way it should behave, people will try this first before trying to escape things. |
| | **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... |
| At line 169 changed one line |
| -- RadomirDopieralski, 2007-01-03 |
| 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}}} | |
| At line 171 changed one line |
| Thanks for the suggestions! (I should try thinking about things from a general user point of view ;-) I've implemented a combination of counting the opening curly braces (to monitor the balance) and treating all closing curly braces as terminators. The parser scans backwards to "adjust" whenever any unbalanced closing curly braces are found. It handles most of the weird combinations I put to it with only a few exceptions (like closing curly braces on the first line and opening curly braces on the last line etc.). It's pretty general, however, I've had to add a special case for inline {{{{{{}}} {{{~}}}}}} to include {{{~}}}}}} inside. I do this by checking for {{{~}}}}}} immediately following the first {{{~}}}}}}. It seems to work but probably needs more testing before I can be sure. |
| 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 ? |
| At line 173 changed 123 lines |
| -- MarkWharton, 2007-01-06 |
|
| I admire your courage with the balancing of braces -- I'd never try it, for I view it as a path to sure madness :). Consider and ASCII-art wiki... Yet it works in similar way to how *we* read text, so maybe it will be "intuitive" after all? Your work is very interesting. |
|
| Another possibility is to use more greedy matching -- always use the last "}}}" as the delimiter. Of course, there is a problem when there are multiple blocks: |
| {{{ |
| {{{ |
| preformatted text |
| ~}}} |
| normal text |
| {{{ |
| preformatted text |
| ~}}} |
| }}} |
| would get parsed as a preformatted text in whole. But we can amend the situation by watching both "{{{{{{}}}" and "{{{~}}}}}}". Basically, the preformatted block continues until we hit the __last__ "{{{~}}}}}}" before "{{{{{{}}}" or end of document. |
|
| This is a loose thought, I haven't tested it. I don't think it gives large improvement over the "multiple consecutive closing braces" rule. |
|
| -- Radomir Dopieralski, 2007-01-06 |
|
| Thanks again Radomir! I find the idea of properly handling unbalanced nesting rather interesting (is it even possible I begin to wonder?). It might turn out to be a can of worms, but anyhow, I think it's worth pursuing a little more. |
|
| I've experimented a little with your idea and it basically works except for an exceptional circumstance with inline preformatted text interfering with block preformatted text! I've put together some rough [preformatted notes|http://www.jynx.com/PreformattedNotes] in an attempt to understand the problem a little better. The page is on my experimental site because it needs to use my parser. It might be too much for a general discussion here, but nevertheless, I intend to draw some conclusions which might be useful in the end. Hopefully there's some magic in there somewhere. |
|
| -- MarkWharton, 2007-01-07 |
|
| I recommend against trying to do anything complex. One way or another, any quoting strategy is going to either leave some results impossible or require escaping. The strategies based on counting or searching for patterns have the disadvantage of being non-local - a change to line 75 can affect the rendering of a pre block on line 15. That guarantees user confusion. |
|
| If you want to leave three close curlies on a line by themselves impossible, the CheatSheet might be possible using indent: |
|
| {{{ |
| {{{ |
| {{{ |
| Preformatted markup |
| ~}}} |
| ~}}} |
| }}} |
|
| But those spaces will interfere with cut and paste. Therefore, I'm in favor of escaping syntax, either tilde or backslash. It will only be used by expert users, but then I think the results will be maximally useful to the people who use the cheat sheet. |
|
| -- RaphLevien, 2007-01-07 |
|
| Well, the brace-counting is definitely not going into Creole as a requirement -- at least I would fight this with all my might -- but of course it's an interesting subject and a great addition "for the ambitious students". |
|
| On the other hand, the rule for including the last "}" seems to be easy to implement in most parsing techniques I can imagine, and greatly reduces the "what the heck is going on?" factor, taking care of the most common use case. This needs testing in practice -- that's why I'd like to have it in draft for at least one version, so that we can receive complaints from implementors if it's hard for them. |
|
| Now, do we have any data on what kinds of markup is used for escaping? |
|
| -- RadomirDopieralski, 2007-01-08 |
|
| Thanks for your comments Raph! It's great to look at all these different ideas. |
|
| Perhaps escaping makes the most sense, in the end. At the same time, it's good to explore the possibilities and find interesting solutions. The methods which I'm testing for myself are working well in most cases and don't require escaping, but at the same time, I admit it's not a general enough solution. |
|
| Let's continue with the escape character discussion in the next round of the spec. If we can find a nice alternative then let's talk about that too. |
|
| P.S. Radomir, exactly, I'm not proposing anything I'm doing for the spec. It's just an interesting technical discussion at this point. |
|
| -- MarkWharton, 2007-01-08 |
|
| I personally like the idea of using a tilde as an escape character. Who would oppose that? |
|
| --[ChuckSmith], 2007 Jan 10 |
|
| ---- |
| !Tilde "~" |
| Advantages: |
| * Used on: |
| ** JSPWiki |
| * Has semantic connotation wit "not", which might suggest the meaning when seen |
| * Pretty rare in normal text (but not unused) |
| Disadvantages: |
| * Not available on many [Keyboards] |
| * Hard to type under Microsoft Windows |
| * Excluded in [Terms] |
| * Traditionally used in text as an alternative to hyphen (eg. in number ranges) or meaning "roughly". |
| * The exact way of escaping is not obvous (eg. compare {{{~ ~}}}}}} vs {{{~ }~ }~ }}}}) |
| * Used in programming languages for operators -- pasted code would need escaping, or could change its meaning. |
| * Conflicts: |
| ** Confluence for user link, |
| ** Netcipia, SnipSnap, XWiki for italics, |
| ** GeboGebo for monospace, |
| ** TracWiki, MoniWiki for strike, |
| ** Confluence, FlexWiki, Instiki, TiddlyWiki, VQWiki for subscript, |
| ** WikkaWiki for bullet list. |
| ---- |
| !Backslash "\" |
| Advantages: |
| * Extremely widespread for escaping in: |
| ** Programming languages |
| ** File names |
| ** Regular expressions and search queries |
| * Traditional, obvious way of use (always escapes a single character) |
| * Never used in normal text |
| * Listed in [Terms] |
| Disadvantages: |
| * Used in Microsoft Windows for paths |
| * Commonly used for forced line break (usually doubled) |
| * Used in programming languages for escaping -- pasted code would need double escaping, or could look bad. |
| ---- |
| !Caret "^" |
| Advantages: |
| * Never used in normal text |
| * Rarely used even in programming languages |
| * Sometimes used to mean "not" |
| Disadvantages: |
| * Excluded in [Terms] |
| * Not on all [Keyboards] |
| * No precedent (?) |
| * Conflicts with superscript markup on all wikis that have it |
| ---- |
| !Percent "%" |
| Advantages: |
| * Commonly used for an alternate escape character, when backslash is not available |
| ** for printf parameters |
| ** for time and date formatting |
| ** for colored text |
| * Established way of using (escapes whole chunks) |
| Disadvantages: |
| * Sometimes used in normal text to denote, uh, percents |
| * Used in programming languages for operators, escaping and variable marks -- code needs escaping or it will change meaning |
| * Conflicts: |
| ** TODO |
| [[spir]] - 15 sept 08 |
.