| At line 9 changed one line |
| -[[ChristophSauer]]: **strongly** avoids conflicts with bold, since using bold at the beginning of lists is not an edge case; intuitive - first guess of endusers; [[not new]]; choice of the vast majority at [Participants at the WMS Workshop, Wikisym 06|People]; singnature/horzontal rule conflicts are easier to solve then conflicts that are introduced by asterisk since space after bullet is not an option. |
| -[[ChristophSauer]]: **strongly** avoids conflicts with bold, since using bold at the beginning of lists is not an edge case; intuitive - first guess of endusers; [[not new]]; choice of the vast majority at [Participants at the WMS Workshop, Wikisym 06|People]; signature/horizontal rule conflicts are easier to solve then conflicts that are introduced by asterisk since space after bullet is not an option. |
| At line 12 added one line |
| -AlexSchroeder: I've seen people use it; but this causes problems if multiple dashes amount to an indented list item, because some people like to sign {{{-- AlexSchroeder}}} at the end of their contribution. |
| At line 18 added 2 lines |
| -AlexSchroeder: Why discard something that works? |
| *[[YvesPiguet]] less common than hyphens in plain text, no conflicts with signatures and rules |
| At line 31 added one line |
| -AlexSchroeder: With an asterix, this eliminates the confusion with simple emphasis often used in plain text, whether the wiki renders it bold or not. Putting a bold word at the beginning of a line only to see it turn into a list item is strange. With a dash, this eliminates the confusion with an ordinary quotation dash used to intrudce a signature. Otherwise a signatures like {{{-- Alex}}} will turn into a list item containing {{{- Alex}}}. That's too surprising. |
| At line 38 added 3 lines |
| -[[AlainDésilets]]: **strongly**, for the same reasons exposed by [[ChristophSauer]]. To which I would add that in my empirical observation of wiki users, I saw many of them type a space after the asterisk, and about as many of them type no space after the asterisk. |
| -[[JaredWilliams]]: Don't see why its necessarry just for disambiguation. |
| * [[YvesPiguet]] most common, provided disambiguation with bold is clearly defined. |
| At line 43 changed one line |
| -[[ChristophSauer]]: **weakly** there should be unified way for parser developers that want to simplify escaping, but it should be optional, since I agree that escaping is hard to understand for endusers. Also it's not Creoles goal to add new markup, that was not there in other engines. Therefore I opt for escape as an addition - a suggestion to solve a certain problem in an more elegant way than using nowiki. |
| -[[ChristophSauer]]: there should be unified way for parser developers that want to simplify escaping. Escape character should be in the core. Without the escape character (be it \ or ~) I feel that the spec is not "round" - we are not giving answers to obvious questions. |
| At line 52 added 2 lines |
| -[[JaredWilliams]]: **weakly**. |
| * [[YvesPiguet]] strongly, much cleaner than triple-braces in some cases. Must be simple, which is very easy. |
| At line 62 added one line |
| -AlexSchroeder: What for? Plus: We don't have a good candidate since \ is used as a path deparator by some operating systems. All proposals are very complicated. |
| At line 72 added one line |
| * [[YvesPiguet]] weakly (backslash also possible if defined cleanly) |
| At line 79 added 3 lines |
| --[[Michele Tomaiuolo]]: backslask-backslash = linebreak; backslash-space = backslash (this is being proposed for tilde also: tilde-space = tilde). See [[Escape Character Proposal]] |
| -[[JaredWilliams]]: generally excepted escape character almost everywhere else. |
|
| At line 77 changed one line |
| -[[MarkWharton]] behavior remains consistent - simple placeholders could be used for inline plain-text nowiki\\For example: this could be how to show {{{<<**>>}}} no wiki type {{{<<//>>}}} characters and text, etc.\\i.e. Placeholders which cannot resolve to a plugin display their text content inline |
| -[[MarkWharton]] behavior remains consistent - simple placeholders could be used for inline plain-text nowiki. For example: this could be how to show {{{<<**>>}}} no wiki type {{{<<//>>}}} characters and text, etc., i.e. Placeholders which cannot resolve to a plugin display their text content inline |
| At line 98 added one line |
| * [[YvesPiguet]] strongly |
| At line 127 added one line |
| * [[YvesPiguet]] strongly |
| At line 132 added 2 lines |
| -AlexSchroeder: I use a variant of nowiki that renders as monospace, and I'm happy with it. No separate solution required. |
| -ChristophSauer: Like Alex: nowiki that renders as monospace, I am happy with it. Wiki markup should be simple. Common things people need. Less choice is better. |
.