Last modified: 2014-09-23 23:43:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3584, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1584 - Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items
Need method for multiparagraph list items, continuing numbered lists, and ass...
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: newparser
: 1115 9342 25587 34564 (view as bug list)
Depends on: 4281 1115
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-24 22:19 UTC by flamurai
Modified: 2014-09-23 23:43 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description flamurai 2005-02-24 22:19:21 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.
Comment 1 flamurai 2005-02-25 20:15:43 UTC
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.
Comment 2 Ryan Proud 2005-10-27 20:13:41 UTC
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.
Comment 3 Ævar Arnfjörð Bjarmason 2005-10-27 20:15:52 UTC
You can just use <ol> and <ul> syntax to achive the desired resaults.
Comment 4 Gil Moses 2006-01-19 07:34:59 UTC
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.
==============


Comment 5 S. McCandlish 2010-06-12 22:25:24 UTC
This bug is clearly a duplicate of Bug #1115, but perhaps more cogent here.
Comment 6 Waldir 2011-04-08 22:43:23 UTC
*** Bug 25587 has been marked as a duplicate of this bug. ***
Comment 7 Sumana Harihareswara 2011-11-06 14:46:01 UTC
*** Bug 1115 has been marked as a duplicate of this bug. ***
Comment 8 Sumana Harihareswara 2011-11-06 14:48:33 UTC
adding "newparser" keyword
Comment 9 G Mo 2011-12-09 19:40:34 UTC
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.
Comment 10 Raimond Spekking 2012-02-21 12:36:12 UTC
*** Bug 34564 has been marked as a duplicate of this bug. ***
Comment 11 Nemo 2014-03-16 12:54:50 UTC
*** Bug 9342 has been marked as a duplicate of this bug. ***
Comment 12 Nemo 2014-03-16 12:58:08 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links