| At line 7 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. |
| 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. |
| At line 13 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. |
| 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. |
| At line 235 changed one line |
| In my preferred version of inline pre (I dislike the term "nowiki" because it doesn't clearly distinguish between simply not processing wiki markup and inline preformatted markup which includes monosopace font), the tilde character is //not// used as an escape. Instead, to address the common case of allowing closing braces at the end of an inline pre span, the pattern for closing such a span is the //last// three closing braces in a span of three or more. The only pattern this does not allow is a pre span followed immediately by a non-pre close brace, with no whitespace in between. It's difficult for me to imagine. |
| In my preferred version of inline pre (I dislike the term "nowiki" because it doesn't clearly distinguish between simply not processing wiki markup and inline preformatted markup which includes monosopace font), the tilde character is //not// used as an escape. Instead, to address the common case of allowing closing braces at the end of an inline pre span, the pattern for closing such a span is the //last// three closing braces in a span of three or more. The only pattern this does not allow is a pre span followed immediately by a non-pre close brace, with no whitespace in between. It's difficult for me to imagine people actually needing this. |
| At line 246 added 162 lines |
|
| Thanks. You're absolutely right that my proposal doesn't allow three closing curly braces in the middle of a single preformatted span, but a passable workaround in this case is to close one span and immediately open another. In other words, to say {{{use {{{three curly braces~}}} for preformatted spans}}}, you'd write: |
|
| {{{ |
| {{{use {{{three curly braces~}}}~}}}{{{ for preformatted spans~}}} |
| }}} |
|
| Obviously, only computer scientists and people with twisty minds will master all the necessary invocations, but that's probably equally true of just about any escape discipline. |
|
| -- [RaphLevien], 2007-01-22 |
|
| Works for me! Cool. I think we should go with your proposal Raph. How does everyone else feel about it? |
|
| -- [MarkWharton], 2007-01-23 |
|
| Ok, so escaping would only work in pre blocks, and only at the beginning of a line. Then I vote for whitespace as the escaping character: |
|
| {{{ |
| {{{ |
| preformatted text |
| ~}}} <-- the single space is removed here |
| ~}}} |
| }}} |
|
| This is the most obvious escaping that users try first (see the examples of pages from sylabus), and the languages that use curly braces are usually not sensitive to indentation (even if so, traditionally at least 4 spaces are used for indenting). |
|
| Of course that makes it impossible to have a "{{{~}}}}}}" indented by a single space anywhere in the pre block -- but the only case where it matters that I can imagine is ascii-art. |
|
| -- RadomirDopieralski, 2007-01-23 |
|
| I think using space in the escape pattern is a good suggestion Radomir. And it could still follow the "put one more than you need to get what see" pattern... so not entirely impossible for ascii-art! I don't see anything necessarily wrong with using space, we're going to have the same problem with whatever character is chosen. Perhaps there's more likely hood of a "collision", that's the only thing that concerns me right now, but otherwise I generally like the idea. |
|
| Actually, I have to add, just tested this in my parser and I really really like it. When you look at the plain text you have a good idea of what's happening. And I'm not so concerned about collision anymore because, after all, we are talking about new lines starting with one or more spaces followed by three closing curly brackets. It should be highly unlikely (and if there's a case where it's required then there's a workaround). |
|
| -- [MarkWharton], 2007-01-23 |
|
| I'm wholeheartedly in favor of Mark's proposal. It has several subtle but significant advantages over a line-noise character. Most important, users are quite likely to stumble over the correct markup just by playing with it. "Hmm, what are the rules for this? If I add spaces, does it still count as the end of the block?" Second, in the (still very unlikely) event of a collision with actual content, the extent of the mangling to the content is to remove a single whitespace. And, of course, the fix is to simply add one more. |
|
| On a more meta note, I'm very pleased with the way this particular discussion has happened. We have three people who care about and understand the issues, and are doing their best to think through all the possibilities to find the best one. On top of that, we have many more who are reading and would point out a serious error and have the opportunity to contribute a brainstorm. The discussion is balanced between theoretical concerns of completeness and practical implementation experience, and keeps entirely to the subject at hand. Would that all controversies in Creole be addressed with such good process! |
|
| -- [Raph Levien], 2007-01-23 |
|
| I think the advantage of a line-noise character is that it can be applied uniformly to all markup. However, if significant whitespace can be applied in the same way, then it's fine for me. I'm just not quite sure how you would escape bold/italic/other markup with spaces? |
|
| -- JanneJalkanen, 2007-01-23 |
|
| Bold/italic/other markup is escaped using the nowiki markup, as the name suggests. |
|
| -- RadomirDopieralski, 2007-01-23 |
|
| DOes anybody see something wrong in this proposal? Is there something to add or discuss further? I'd like to propose including this in Creole 0.4 in (more or less) current form if there are no further issues related to this. |
|
| -- RadomirDopieralski, 2007-01-25 |
|
| I'm happy with everything. Thanks Raph and Radomir, I've enjoyed the discussions! I think the outcome is really a group effort. To see all the different ideas, problems, solutions, has been a great experience for me. |
|
| -- [MarkWharton], 2007-01-25 |
|
| Maybe I've lost something, but... is there a way to escape 3 curly braces in //in-line// nowiki sections? |
|
| -- [[Michele Tomaiuolo]], 2007-02-14 |
|
| The [[AddNoWikiEscapeProposal]] solution for nowiki includes any trailing "}" into the nowiki span. This means only the final three curly brackets are treated as termination. For cases where {{{~}}}}}} is required in the middle of a nowiki span, simply close one span and immediately open another. See Raph's last entry dated 2007-01-22 above for specifics. |
|
| -- MarkWharton, 2007-02-14 |
|
| Thanks Mark. Including trailing braces is simple and feasible. |
|
| But what about a "}}}" sequence in the middle of a nowiki section? I don't like the close-and-open hack very much. |
| We should find a more generic, 'clean', short-to-type, easy to learn and teach solution, IMO. |
|
| Simple parsers could interpret this hack as "close a tag, open another". Not a desirable behaviour. |
|
| I think we should find a way to break the closing sequence - for example to "} } }" - and then remove added characters (spaces?). Something like what we do for nowiki blocks. A single solution working in both cases would be better, though. |
|
| -- [[Michele Tomaiuolo]], 2007-02-14 |
|
|
| Using space as escape character for nowiki/preformatted might work, but we need a general discussion about a escape character, that alsow works for headings, lists etc. Space is not a solution here. I would like to ask you to join the discussion about a general strategy on the [[Escape Character Proposal]], to achive a consistent way of escaping. |
|
| -- [[ChristophSauer]], 2007-02-22 |
|
| A way to escape "}}}" in inline nowiki sections is also needed. I see three main alternatives: |
|
| # Add a space after each "}" in the text. Then decrease the number of spaces after each "}" in the output. Quite intuitive IMO. But spaces are very frequent and users would need to add one more if they want some spaces after a closing brace. |
| # Add a dash (or another char) after each "}". Then decrease the number of dashes after each "}" in the output. Low probability of collision. Not as intuitive as space. |
| # Use the general escaping mechanism. But that would require user to take care of the escape char, when it appears in nowiki text. |
|
| -- [[Michele Tomaiuolo]], 2007-03-05 |
|
| Just to clarify, this substitution would work for both blocks and inline nowiki sections: |
|
| {{{ |
| "/} ( *)(?=})/" |
| => |
| "}$1"; |
| }}} |
|
| The rule "to include any trailing '}' into the nowiki span" should also be applied. |
|
| -- [[Michele Tomaiuolo]], 2007-03-05 |
|
| Currently, the escape sequence for triple-right-brace in nowiki is {{{ }} }} }}{{{ }}} (without the spaces, |
| which I've added because wikicreole doesn't support Creole 0.5 yet). Do we need more than |
| that and normal escape character? |
|
| -- [[YvesPiguet]], 2007-03-05 |
|
| == Nowiki: really? |
|
| Sorry for getting so late into the discussion, but I'd like anyway to tell my opinion about the matter: as [[Michele Tomaiuolo]] said, the tilde character cannot be typed in Italian keyboards (and I guess in other keyboards too) if not through a BlocNum Alt+ASCII combination. |
| (Note: I have recently added the {{{ nowiki }}} syntax to [WikiOnAStick] in the not-yet-released v0.9.3 Beta) |
| I am totally against an escape character in our wiki syntax because it looks like a mind trap to me, and it might make the WikiCreole rules complex and hard to learn. |
|
| I will explain what's the best solution in my opinion: |
| * no escape character either inside the {{{ nowiki }}} blocks and in the normal wiki source |
| * support of a "raw" transclusion |
|
| When your file includes the "}}}" you'd have to create a wiki page which will never be directly accessed but inline-transcluded in raw mode and shown without any wiki parsing. |
| This would also be efficient in case of big ASCII files. |
|
| -- [[DanieleC.]], 2007-Jul-05 |
|
| The tilde is used in many programming languages and shells. I don't understand why an unused AltGr key combination isn't used |
| on PC. Mathematica [[http://support.wolfram.com/mathematica/international/italiankit/keyboard.html|hints]] at a utility to add the tilde. On Mac, there is no such problem. [[http://en.wikipedia.org/wiki/Keyboard_layout]] shows that among roman keyboards, icelandic, hungarian and romanian layouts lack the tilde too. If you feel the escape is important in your wiki, you could explain how to type them |
| with Alt, or have a button with Javascript to insert the character; otherwise, no problem... |
|
| The motivation for the tilde has already been discussed at length. Raw transclusion has pluses and minuses, but it isn't suitable in all situations (not all converters can fetch secondary files). |
|
| -- [[YvesPiguet]], 2007-Jul-05 |
|
| Sorry for the apparently trivial reply: the average user won't type a character that he does not see on the keyboard ([AvoidSpecialCharacters]), I really feel that a slice of users is cut apart with the tilde - but if it's not the biggest slice, it could be anyway a good compromise. |
|
| About raw transclusion: it is (in my opinion) the only "clean" solution because it would separate the raw block of text from the wiki markup text, any other solution would require to modify the raw block of text. Just my 2cents; by the way, thanks for the additional informations. |
|
| -- [[DanieleC.]], 2007-Jul-06 |
|
| === User-defined block terminator === |
|
| Here is one more idea for nowiki-block termination syntax - let user define the terminator: |
|
| {{{ |
| {{{TERM1 |
| nowiki-text |
| TERM1~}}} |
|
| {{{MY-DELIMITER-2 |
| another nowiki-text, which can contain even TERM1~}}} |
| MY-DELIMITER-2~}}} |
| }}} |
|
| It can be used by advanced wiki users, who can include everything they like into nowiki-blocks in this way. Basic Creole 1.0 syntax is compatible with this concept (user-defined terminator defaults to empty string). |
|
| Same idea is used in Perl for example: |
|
| {{{ |
| print <<EOT; |
| blabla |
| EOT |
| }}} |
|
| -- [[YaroslavStavnichiy]], 2007-12-15 |
.