At line 373 changed one line |
For Creole 0.4 I'd like to bring out the issue of spaces after the bullets. The current (0.3) draft and previous specs have this ugly special case: |
Moved part of discussion to [Talk.RequireSpaceAfterBulletProposal]. |
---- |
At line 376 added 11 lines |
How about allowing spaces __in between__ the atserisks/hashes? I've seen at least one user trying to escape the bold markup this way and I think it's pretty creative. Would it collide with something? |
|
-- RadomirDopieralski, 2007-01-22 |
|
Here is another problem, maybe someone can give some advice. My parser coudn't handle the "smart" resolving of ambiguity between bold and second-level lists, because of its construction: |
|
It parses the text in two passes, using two regular expressions. The first regular expression divides the text into block-level elements, deciding also of the block type. The decission is final and cannot be changed later. The second pass is performed for some blocks only and it handles the character-level markup like bold and italics and links. |
|
Up until now every list item was considered a separate block-level element. Since the division was made using a single regular expression, and the lookbehind patterns are required to have fixed length, I couldn't find a way to implement the context-depended special case (where {{{**}}} at the beginning of the line is a list only, if there is a {{{*}}} at the beginning of the previous line). |
|
No I'm trying a different approach: treat the whole list as a block element, and divide it into list items in an additional, intemediate pass. I thought that I can just require the list block to start with a single asterisk or hash, and treat everything else as normal paragraph -- then the bold would be properly handled in the second pass. But I was too optimistic. This is a properl list (according to the current Creole spec) even when it starts with multiple asterisks: |
At line 376 changed one line |
About unordered lists and bold: a line starting with ** (including optional whitespace before and afterwards), immediately following an unordered list element a line above, will be treated as a nested unordered list element. Otherwise it will be treated as the beginning of bold text. Also note that bold and/or italics cannot span lines in a list. |
***first list item bold** |
* second list item |
** sublist |
At line 379 changed one line |
I think it's ugly and complicates the parser needlessly. Also, many wikis already have very similar list markup, just without this special case -- making them accept both Creole and native markup at the same time would require some sort of a hack (I can't even imagine it curently). |
Now I'm buffled. How to recognize that a block of text is a list without parsing all the character-level markup inside it first? |
At line 381 changed one line |
One possible way of getting rid of that special case and still keeping list markup unambigous with bold markup is //requiring// a space after the bullet. |
-- RadomirDopieralski, 2007-02-05 |
At line 383 changed one line |
Now, this is a different case than with space //before// the bullet. There are wiki engines that don't allow space before the bullet, and those that require it -- making it optional is really the only way to make them agree. |
Question: How is the following markup should be rendered? |
At line 385 changed one line |
On the other hand, no wiki engine I know prohibits the space after the bullet. Some require it. |
{{{ |
# first list item |
# second list item |
**continued bold on the next line** |
}}} |
At line 387 changed one line |
Moreover, putting a space after most punctuation characters is a tradition, and for many people -- a reflex. I can see nothing unnatural in requiring it -- and it simplifies the parsers and the specs -- making Creole both easier to implement and to teach. |
I think we should require nested list characters match like this (MediaWiki style): |
At line 389 removed one line |
By the way, there is a (pretty ugly) hack to get a bold line even if the above special case is removed (remove the single space): |
At line 391 changed one line |
{{{}} }**bold line** |
* One |
*# Two |
*#* Three |
At line 393 removed one line |
-- [[RadomirDopieralski]], 2006-12-14 |
At line 395 changed one line |
Why not accept both (asterisks and dashes)? And it goes with the unofficial [Goals] {{{Rule of least surprise}}} and some others... |
then the first sample above can be easily resolved as bold continuation, which a user would more naturally be expecting, in my point of view. |
At line 397 changed one line |
-- [EricChartre], 2006-12-28 |
Although this is not resolvable in this way: |
{{{ |
* first list item |
* second list item |
**continued bold on the next line** |
}}} |
At line 399 changed one line |
Regarding the possible ambiguity of the asterisks, there are none (for the parser anyway) if the specs do not allow for bold text to span multiple lines and that bold text must end at some point with **. Also, I __don't__ think that a user would ever, on purpose, do something like: |
One more example: |
{{{ |
# first list item |
# second list item |
* - what is this? |
an asterisk in continuation of second list item, |
a third list item, |
or first item of a new list? |
}}} |
At line 432 added 3 lines |
This can only be resolved to literal asterisk if we require blank lines between adjacent but not connected list blocks. I don't think that it is necessary. I think this should rather be rendered as a first item of a new list. A single asterisk in the beginning of line should always be escaped - in list items as well as in paragraphs. |
|
And one more: |
At line 402 changed 2 lines |
** is this text bold |
** or are these just two second-level list items |
* One |
*# One.Two |
*#* One.Two.Three |
* Two |
# One |
#* One.Two |
#*# One.Two.Three |
At line 406 changed one line |
meaning |
I think here we have two not connected lists. Same as below: |
{{{ |
* One |
*# One.Two |
*#* One.Two.Three |
* Two |
At line 452 added 6 lines |
# One |
#* One.Two |
#*# One.Two.Three |
}}} |
|
What about this: |
At line 409 changed 2 lines |
<em> is this text bold<br /> |
</em> or are these just two second-level list items |
# One |
#** Two bold |
#*# Two.Three (with literal # in front) |
At line 464 added one line |
Note: this wiki renders it with a bug (bold is not closed and goes up to my signature): |
At line 414 changed one line |
However, the parser must do a look-ahead or a two-level parsing... |
# One |
#** Two bold |
#*# Two.Three (with literal # in front) |
At line 416 changed one line |
-- [EricChartre], 2006-12-28 |
|
Any comments? |
|
-- YaroslavStavnichiy, 2007-12-17 |