Last modified: 2014-09-24 01:32:20 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 T3115, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1115 - Newline as list item terminator is troublesome
Newline as list item terminator is troublesome
Status: RESOLVED DUPLICATE of bug 1584
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: need-parsertest, newparser, patch, patch-reviewed
: 2280 5308 6677 8318 12449 13642 (view as bug list)
Depends on:
Blocks: 1581 1584 9342
  Show dependency treegraph
 
Reported: 2004-12-16 17:26 UTC by David Coppit
Modified: 2014-09-24 01:32 UTC (History)
15 users (show)

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


Attachments

Description David Coppit 2004-12-16 17:26:44 UTC
Currently, list items are terminated by a newline. I'd like that rule to be
modified so that list items are terminated when the next line begins with some
sort of list specifier, or when the next line is empty (or perhaps only
whitespace). Lines that begin without list specifiers should be treated as
separate paragraphs.

The current rule makes it very troublesome to create list items with multiple
paragraphs, and as far as I can tell, there is no way to embed preformatted text
in a list item. For example:

# This is the first list item, first paragraph
This is the first list item, second paragraph
  Here is some preformatted text with the first list item
  Here is the rest of the preformatted text
# This is the second list item (numbered as 2)

With the current rule, the above is rendered as a single item list, then a plain
text paragraph, then a preformatted text paragraph, then a second single item
list whose number starts with 1. This makes it difficult to create sophisticated
lists. Under my proposed change, the above would be rendered instead as a single
list, where the first item contains two plain text paragraphs and one
preformatted text paragraph.

This change is mostly compatible with current Wiki pages, since most authors
would normally place an empty line after their list before starting non-list
text. One could justify the use of a single newline to start a new paragraph
instead of an empty line because one is in a list context. (i.e. the whole list
is a single paragraph.)

By the way, as a workaround I'm manually numbering my paragraphs:

1. This is the first list item, first paragraph

This is the first list item, second paragraph

  Here is some preformatted text with the first list item
  Here is the rest of the preformatted text

2. This is the second list item (numbered as 2)

Please let me know if you have a better workaround.
Comment 1 Toshi Meier-Brook 2005-03-02 16:44:49 UTC
Severe problems arise when Users break <a href= >.. </a> pairs by a newline.
Then the list item tag is closed </li> before the <a>-tag is closed, resulting
in incorrect HTML-code:

Example Wiki Code:
<pre>
# [[WikiArticle_with_a_very_long_name_going_right_to_the_end_of_the_line|
Short Description]]
</pre>

Results in the following code:

<pre>
 <ol><li> <a
href="/WikiDev/index.php?title=WikiArticle_with_a_very_long_name_going_right_to_the_end_of_the_line&amp;action=edit"
 class="new" title ="WikiArticle with a very long name going right to the end of
the line">
 </li></ol>
 <p>Short Description</a>
</pre>

This code might not be rendered correctly by all available browsers.
Comment 2 Charles Sutton 2005-05-18 21:18:04 UTC
This seems to be very similar to bug 1584.  Probably one of them should be
marked as dup, but not sure which...
Comment 3 Brion Vibber 2005-06-01 05:48:27 UTC
*** Bug 2280 has been marked as a duplicate of this bug. ***
Comment 4 JiangXin 2005-11-17 06:52:36 UTC
I have fixed this bug, patch is here: 
http://meta.wikimedia.org/wiki/User:Jiangxin/Patch_Blankline_As_List_Terminator

wiki code:
======================
#item 1
blah blah blah...
##item 1-1 \
continued
blah blah blah...
##item 1-2
<pre>
pre text of item 1.2

above is a blank line
# in pre block
* in pre block

</pre>
#item 2
#:<pre>
blah blah blah...
</pre>

another paragraph.

rendered as:
======================
<ol><li>item 1<br>
blah blah blah...
<ol><li>item 1-1 
continued<br>
blah blah blah...
</li><li>item 1-2<br>
<pre>
pre text of item 1.2

above is a blank line
# in pre block
* in pre block

</pre>
</li></ol>
</li><li>item 2
<dl><dd><pre>
blah blah blah...
</pre>
</dd></dl>
</li></ol>
<p>another paragraph.
</p>
Comment 5 eminencja 2006-02-02 20:57:18 UTC
JiangXin patch (comment 4) looks cool. But here is another suggestion: 

Let me explicitly start and terminate lists. 

A list sould be started with #( and terminated with )#. 
The #( string should be translated to <OL><LI>; 
)# should terminate the list with </OL>.

List items should be entered as usual, with a hash #.

A similar extension should be used for bulleted lists, i.e. *( and )*. 
Note that such markup should be fairly easy to parse.
Comment 6 Brion Vibber 2006-03-21 20:53:34 UTC
*** Bug 5308 has been marked as a duplicate of this bug. ***
Comment 7 A2 2006-03-21 21:24:22 UTC
This is how to fix it (also filed in bug 5308 at http://bugzilla.wikimedia.org/show_bug.cgi?id=5308):

LET ME EXPLICITLY START AND TERMINATE LISTS.

A list could be started with #( and terminated with )#. 

The #( string should be translated to <OL><LI>; )# should terminate the list with </OL>.

List items should be entered as usual, with a hash #.

A similar extension should be used for bulleted lists, i.e. *( and )*.

Note that such markup should be fairly easy to parse. It also does not conflict with existing pages. 
Both types of lists styles can co-exist in one document! Editors can continue to use # or * for 
simple lists and #( )# or *( )* for more complex layouts.
Comment 8 Brion Vibber 2006-03-21 22:21:29 UTC
That would obviously conflict with any list where "(" appeared right
at the start of the line. I'm not sure it looks terribly obvious or
attractive either. Can you provide a sample of what this would look
like in use?
Comment 9 A2 2006-03-22 19:27:59 UTC
Ad. 8

True, in the unlikely scenario that a "(" starts the list item the rendering would change. But the 
remedy is easy -- if you really want to start a list item with a "(" -- put a space after the 
asterisk/hash, like that
* (
# (
BTW, can you find _one_ wiki page that uses list items starting with a "("? I couldn't ;-)


How that would look in real use?

Ok, I want to have a list with three numbered items showing three steps needed to configure 
something. I want a screenshot and paragraph with preformated text in the list. This is how I would 
do it with the #( )# syntax:
 
=== Configuring E-mail ===

#( To use a fancy signature go to the http:/blah url, log in and click the Mail tab. Your screen 
should look like in the figure below

[[Image:000.png]]

# Select the "Send e-mail in HTML format" checkbox.

# Put the following HTML code into the signature field:

 <B>Joe Average</A>
 <FONT COLOR="blue">Shown in Wiki using preformatted text</FONT>

Click Save when you are done.
)#

That would be rendered as a numbered list, with three items. The list starts with #( and terminates 
with )#. 
Comment 10 lɛʁi לערי ריינהארט 2006-03-22 19:46:58 UTC
Is Bug 5121: Virtual lines using a trailing escape character (as "\")
about the same topic?
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-17 04:20:31 UTC
(In reply to comment #8)
> That would obviously conflict with any list where "(" appeared right
> at the start of the line. I'm not sure it looks terribly obvious or
> attractive either.

The consistent thing would be to borrow from table markup.  Use {#, {*, {;/{: to
begin the respective lists, and #} *} ;}/:} to end them.  A line-initial {#
followed somewhere before the end of the page by a #} is quite unlikely, and
likewise for all the rest.
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-17 04:21:10 UTC
*** Bug 6677 has been marked as a duplicate of this bug. ***
Comment 13 A2 2006-07-18 17:07:59 UTC
(In reply to comment #11)
> 
> The consistent thing would be to borrow from table markup.  Use {#, {*, {;/{: to
> begin the respective lists, and #} *} ;}/:} to end them.  A line-initial {#
> followed somewhere before the end of the page by a #} is quite unlikely (...)

Ok -- I do not care about the character combination -- as long 
as I am able to __explicitly__ close lists I'll be happy :-)
Comment 14 Wytze van der Ploeg 2006-08-22 10:16:28 UTC
Why isn't JiangXin's patch applied in the current versions?
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-22 16:45:30 UTC
Because devs are not always willing to spend their time looking over submitted
patches.  This is a volunteer project, remember.  The patch will also break
existing behavior by continuing a list item where currently the entire list is
ended.
Comment 16 Stijn Hoop 2007-03-23 09:23:34 UTC
I keep running into this while attempting to use MediaWiki as our helpdesk
procedure reference. It is *very* common in that scenario to want to show some
commands to type using e.g. <pre> in a list item (step 10 of 20). While I can
see that simply applying JiangXin's patch might break existing pages, the ideas
from comment 9 and comment 11 sound like a nice addition to the current markup.
No I don't have a patch, just commenting to let people know I'd love this
feature too, and I think it's important.
Comment 17 Anon Sricharoenchai 2008-04-29 06:32:36 UTC
(In reply to comment #11)
> 
> The consistent thing would be to borrow from table markup.  Use {#, {*, {;/{: to
> begin the respective lists, and #} *} ;}/:} to end them.  A line-initial {#
> followed somewhere before the end of the page by a #} is quite unlikely, and
> likewise for all the rest.

{#, {*, {;, and {: should be unified into only one markup.
MediaWiki should automagically determine the first item inside it, whether it is *, #, ;, or :.

Example (when unified to {* ),

{*
# aaa
....
# bbb
*}

{*
* aaa
....
* bbb
*}
Comment 18 S. McCandlish 2010-06-12 22:26:46 UTC
Bug #1584 is clearly a duplicate of this one, but perhaps more cogent over there.
Comment 19 Chad H. 2010-10-19 17:22:20 UTC
*** Bug 12449 has been marked as a duplicate of this bug. ***
Comment 20 Chad H. 2010-10-19 17:22:45 UTC
*** Bug 13642 has been marked as a duplicate of this bug. ***
Comment 21 Chad H. 2010-10-19 17:22:53 UTC
*** Bug 25587 has been marked as a duplicate of this bug. ***
Comment 22 Dan Barrett 2010-10-19 19:13:37 UTC
It's all well and good to mark my bug 25587 as a duplicate, but this issue has been open since 2004 (six years).  I believe my approach (in bug 25587) is the simplest yet proposed and should not break existing wiki articles. Most other approaches talk of explicitly opening and closing lists. My approach is simply "continue the previous list."
Comment 23 Sumana Harihareswara 2011-11-06 14:46:01 UTC
I am agreeing with S. McCandlish that this issue is a subset of the issues discussed in bug #1584, so I am marking this a duplicate of that.

Also, I'm removing the "need-review" keyword and adding the "reviewed" keyword, because Aryeh reviewed the submitted patch by saying: "The patch will also break existing behavior by continuing a list item where currently the entire list is ended."

This issue also bothers me, so I'm going to add myself to the cc list for bug #1584 and I suggest you do the same, if you haven't already.  Brion Vibber and Gabriel Wicke are currently working on rewriting the parser to fix issues like this one, hence the "newparser" keyword on this bug and on bug #1584 -- to follow their work, subscribe to https://lists.wikimedia.org/mailman/listinfo/wikitext-l .

*** This bug has been marked as a duplicate of bug 1584 ***
Comment 24 Nemo 2014-03-16 12:45:34 UTC
I'm not sure this is a duplicate; this bug has a more generic summary which also covered some of the issues/solutions which have been duped to it, while bug 1584 is about one specific use case.
Comment 25 Nemo 2014-03-16 12:52:07 UTC
*** Bug 8318 has been marked as a duplicate of this bug. ***

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


Navigation
Links