| At line 52 changed 3 lines |
| In preformatted blocks, triple braces are only recognized as the end marker at the very beginning |
| of a line. Google code finds 200 matches, which is probably acceptable, since braces can be made |
| meaningless to the Creole parser with a single leading space. |
| In preformatted blocks, triple braces are only recognized as the end marker at the very beginning of a line. Google code finds 200 matches, which is probably acceptable, since braces can be made meaningless to the Creole parser with a single leading space. |
| At line 56 changed 3 lines |
| In inline nowiki, triple braces could cause problems only when followed by something else, which |
| has been considered here (rightfully imo) as an edge case. Workarounds exist, such as two successive |
| inline nowikis. |
| In inline nowiki, triple braces could cause problems only when followed by something else, which has been considered here (rightfully imo) as an |
| edge case. Workarounds exist, such as two successive inline nowikis. |
| At line 60 changed 2 lines |
| Your last search shows that no fix end marker is safe. User-selected end markers would probably |
| make some implementations much more complicated. |
| Your last search shows that no fix end marker is safe. User-selected end markers would probably make some implementations much more complicated. |
| At line 60 added 27 lines |
|
| I can't believe the 200 number. Right now a google code search for ^}}} (triple close brace at the start of a line) shows not 200 but 30,000 matching files. |
|
| (The regexp that better matched your definition, namely ^}}}*$, actually matched about half as many, which suggests the code search may still be borked. Google code search was clearly borked last night. A google engineer emailed me today to say he thought it was now fixed, but I don't believe him. Regardless of google code search, I am sure I've written and read occurences of }}} in a line on its own within code, which is why I'm convinced the 200 count (which translates to "very rare") is wildly inaccurate even if the 30,000 count is also inaccurate.) |
|
| I agree that user-selected end markers would suck for the reason you outlined. |
|
| So, I still think you need to pick something other than triple braces, and I still think you should test proposals with google code search, but I agree you won't get a perfect pick and should instead pick a straight double or triple and I wish to emphasize that, while Google code search results should be checked, the result //counts// should be viewed with some suspicion for the time being. (Fwiw, I've posted [[http://groups.google.com/group/Google-Code-Search/browse_thread/thread/72d626abc26db050/#|a message]] to try prod google labs into fixing/improving the counts.) |
|
| -- [[RaiphMellor]], 2007-Apr-20 |
|
| Here is my search: [[http://www.google.com/codesearch/advanced_code_search?hl=fr&q=+%5E%7D%7D%7D]] (advanced search with regexp caret-rightbrace-rightbrace-rightbrace). It still returns |
| 200. Now I can't exclude Google takes into account that I'm located in Switzerland and I speak |
| French... |
|
| Writing triple-braces alone is a matter of style. In languages which use braces for block begin/end |
| markers, I'd expect multiple braces mainly in compact one-line expressions, such as macro |
| definitions and JavaScript inline code, and maybe in code generated automatically. I'm not that |
| surprised. |
|
| -- [[YvesPiguet]], 2007-Apr-21 |
|
| Most wiki engines (the NoWikiMarkupComparison is not finished yet, I have no free time recently) use exactly this syntax, and I don't remember **anyone** complaining, even on higly C- and Java-centered wikis. The truth is that most any language that uses braces to markup blocks also ignores whitespace, so it's very easy to prevent the {{{~}}}}}} from interfering. In addition, the non-indented braces are only likely at the end of pasted code, so it's easy to space-stuff them. |
|
| I think we should rather use dice rolls to check our markup, as it seems to be much more reliable than google code search and gives much more consistent results. I just repeat Yves' and Raiph's searches, and the outcome is truly amusing: the search for {{{^~}}}}}} returns 200 hits, while the search for more restrictive pattern {{{^~}}}\s*$}}} returns 300 hits. Then again, search for the most restrictive {{{^~}}}$}}} gives 18000 hits. Clearly a great thing to base our standards on. |
|
| -- [[Radomir Dopieralski]], 2007-Apr-21 |
.