Last modified: 2014-09-23 23:43:30 UTC
ISSUE 1: With the current Wiki syntax, I can't do something like: 1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer molestie. Cras sed wisi. Aliquam imperdiet, pede a fermentum ullamcorper, felis ligula molestie orci, in cursus nulla velit vitae enim. Suspendisse suscipit. Suspendisse potenti. Suspendisse potenti. Curabitur tempor augue. 2. Donec vitae ligula. In nonummy justo id magna. Praesent mollis imperdiet velit. Curabitur dolor. ISSUE 2: I can't also get: There are five things you have to do. The first three are really annoying: 1. Praesent pretium augue nec est. 2. Donec viverra wisi tempor justo. 3. Pellentesque habitant morbi tristique. The last two are fun. 4. Etiam interdum congue urna. 5. Suspendisse consequat nonummy leo. PROPOSED SOLUTIONS TO ISSUES 1 AND 2: There needs to be some sort of markup to avoid HTML and hard numbering lists that allows you to group lists together. For the first issue, this makes the most sense to me: # This is the first paragraph of list item one. > This paragraph is a continuation of list item one. > This is the third paragraph of list item one. # This is list item two. This would also work with bulleted lists: * This is the first paragraph of list item one. > This paragraph is a continuation of list item one. > This is the third paragraph of list item one. * This is list item two. This should produce the following output in either case: <li> <p>This is the first paragraph of list item one.</p> <p>This paragraph is a continuation of list item one.</p> <p>This is the third paragraph of list item one.</p> </li> <li> <p>This is list item two.</p> </li> My suggestion for the second issue would be: # Item one # Item two Some descriptive text #^ Item three # Item four The caret means it should continue from the above list. I don't think HTML4/XHTML1 has a way to do this automatically, so the parser would have to keep track of the current list count and use the li value attribute to start the list at the proper number. ISSUE 3 AND PROPOSED SOLUTION: You can't assign a specific value to an ordered list item. This is important when quoting a partial list from an outside source. Hard-numbering the list is a bad idea because it produces a different style, mainly, it doesn't indent the text. I propose the following solution #3# This is list item 3 #442# This is list item 442 # This is list item 443 #37# This is list item 37 Some body text #^ This is list item 38 # This is list item 39 For similarilty, it might be wise to alter the caret notation to have a trailing hash mark as well: #^# instead of #^, though it doesn't seem absolutely necessary because I can't think of many phrases that need to start with a caret. If the parser encounters bad markup inside the hash marks (e.g. #stupid#), it should just treat it as a regular list item in the sequence.
Thinking about it some more, #number# isn't ideal. One should be able to get something like: 6. 5. 4. list item With that syntax, it would be: #6##5##4# which could be a little bit confusing. So we need another delimiter, mainly because we don't want to break list items that begin with numbers. I think the pipe character works okay here. Is it best to require it just at the end, though? #6|#5|#4| would be the "full" version #6#5#4| isn't ambiguous, though. I think both versions could work and be supported. Even #6**:#5| is fine I forgot to think about multi-level lists in my original proposal, and they make the problem a little bit trickier. Once again, the caret doesn't need a closing delimiter. #^#^#5#^#9#^#^ 4 out of 5 doctors recommend Marlboro Lights ... no ambiguity there. For the multiparagraph list item, we have to remember where we are in the list. Digging through the code a little, it doesn't do that right now. It's just parsing lists on a line-by-line basis with no knowledge of the past line. We'd have to remember: (1) are we still in a list? (2) what type of list are we in? This way we can call closeList(.) and get the right closing parameters. The other issue here is that something like this should be valid: ## list item #> continuation #># new list started in continuation which would produce: <ol> <li> <ol> <li> <p>list item</p> <p>continuation</p> <ol> <li>new list started in continuation</li> ... The CSS is also going to need to be tweaked a bit because <li><p>...</p></li> adds excess space around list items, but this is semantically correct. Not a huge problem, just something to add to the todo list.
I'm having a similar issue when trying to add a block of formatted text (pre) as a member of a list, only the first line is actually included in the block.
You can just use <ol> and <ul> syntax to achive the desired resaults.
Hi, I came here after having been annoyed over the same situation. Good suggestion, I'd like to also see a more complete suggestion containing sub-paragraph numbering. The main idea should be utilizing a character for 'Continue numbering' operation. e.g.: =============== # Lorem ipsum ## dolor sit amet, consectetuer adipiscing elit. Integer molestie. ##^ Cras sed wiki. ==============
This bug is clearly a duplicate of Bug #1115, but perhaps more cogent here.
*** Bug 25587 has been marked as a duplicate of this bug. ***
*** Bug 1115 has been marked as a duplicate of this bug. ***
adding "newparser" keyword
I'd like to point out that the inability to drop CODE, PRE, and SyntaxHighlight_Geshi multiline blocks is a big limiting factor in using Mediawiki for programmers' wikis. I spearheaded a switch from MoinMoin to MediaWiki at my company, and the #1 biggest endless gripe from users is the inability to have multiline blocks that work properly in lists. The users also dislike the "just use HTML" answer despite being web app developers, FWIW. Having to fall back to HTML makes the tool less convenient. I know that MediaWiki is developed largely for Wikipedia, but its other features make it excellent for internal wikis used for software development. This is the main sore point.
*** Bug 34564 has been marked as a duplicate of this bug. ***
*** Bug 9342 has been marked as a duplicate of this bug. ***
(In reply to Ævar Arnfjörð Bjarmason from comment #3) > You can just use <ol> and <ul> syntax to achive the desired resaults. I still don't see an answer to this very sensible concern. Isn't this extremely generic bug asking, in practice, to reinvent the whole <ol> and <ul> syntax in wikimarkup? Because that wouldn't make any sense. We should instead identify specific pain points which make the output of the syntax more sensible without making it more complex. Some of the duplicates of this bug and of bug 1115 give such examples and proposals.
