Need method for multiparagraph list items, continuing numbered lists, and assigning specific numbers to list items
Closed, DuplicatePublic

Description

Author: flamurai

Description:
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.
  1. 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.

  1. Etiam interdum congue urna.
  2. 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:

  1. Item one
  2. 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.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=53620
https://bugzilla.wikimedia.org/show_bug.cgi?id=1581

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz1584.
bzimport created this task.Via LegacyFeb 24 2005, 10:19 PM
bzimport added a comment.Via ConduitFeb 25 2005, 8:15 PM

flamurai wrote:

Thinking about it some more, #number# isn't ideal. One should be able to get
something like:

  1. 5. 4. list item

With that syntax, it would be:

#654#

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.

bzimport added a comment.Via ConduitOct 27 2005, 8:13 PM

ryan wrote:

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.

bzimport added a comment.Via ConduitOct 27 2005, 8:15 PM

avarab wrote:

You can just use <ol> and <ul> syntax to achive the desired resaults.

bzimport added a comment.Via ConduitJan 19 2006, 7:34 AM

gil wrote:

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.:

  1. Lorem ipsum
    1. dolor sit amet, consectetuer

adipiscing elit. Integer molestie.

^ Cras sed wiki.

bzimport added a comment.Via ConduitJun 12 2010, 10:25 PM

smccandlish wrote:

This bug is clearly a duplicate of Bug #1115, but perhaps more cogent here.

waldyrious added a comment.Via ConduitApr 8 2011, 10:43 PM
  • Bug 25587 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitNov 6 2011, 2:46 PM

sumanah wrote:

*** Bug 1115 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitNov 6 2011, 2:48 PM

sumanah wrote:

adding "newparser" keyword

bzimport added a comment.Via ConduitDec 9 2011, 7:40 PM

gmorehouse wrote:

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.

Raymond added a comment.Via ConduitFeb 21 2012, 12:36 PM
  • Bug 34564 has been marked as a duplicate of this bug. ***
Nemo_bis added a comment.Via ConduitMar 16 2014, 12:54 PM
  • Bug 9342 has been marked as a duplicate of this bug. ***
Nemo_bis added a comment.Via ConduitMar 16 2014, 12:58 PM

(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.

Jdforrester-WMF removed a project: Newparser.Via WebThu, Jun 4, 9:39 PM

Per T3115#53278, it's rather the opposite IMHO if we must merge.

Add Comment