Specifying starting value of a numbered list

List overview All Threads
Download

newer

older

Why use innodb in this case ?...

mediawiki source code directory...

Paul Grinberg

3 Aug 2007 3 Aug '07

2:14 p.m.

Hello, I have been maintaining my company's wiki for some time now. The number one concern that has been expressed throughout the wiki's existence is that numbered lists cannot be restarted. For example, numbered lists are a perfect solution for procedure documentation. However, oftentimes it is necessary to insert a <pre>, <div>, or even wiki-syntax table between two consecutive steps. In the current wiki implementation, Parser.php restarts the numbered list back at #1 after such an interjection. Am I missing something? Is there a mechanism to embed these (and possible other) non-numbered list items in a numbered list? If there currently isn't a way to do so, then I'd like to see if there is currently any effort to hack/redesign the Parser to accept some new syntax (backwards compatible, of course) to allow for starting a numbered list at any user defined value? And if there isn't such an effort already, then I'd like to give it a try myself (I've looked at the code already and have a pretty good idea on how to do it). Thanks in advance! ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC

Show replies by date

Merlijn van Deen

3 Aug 3 Aug

3:08 p.m.

...

Is there a mechanism to embed these (and possible other) non-numbered list items in a numbered list?

I can think of two ways: template 'orderedlist', contents '<ol{{#if:{{{start|}}}| start={{{start}}}}}>{{{1}}}</ol>' template 'listitem', contents '<li>{{{1}}}</li>' Usage: {{orderedlist|start=10|1= {{listitem|text}} {{listitem|1= text <div>text in div</div> etc}} }} A second way would be to split the start and end tags in two seperate templates. Both are not exactly great solutions, but changing the parser is related to masochism ;)

...

If there currently isn't a way to do so, then I'd like to see if there is currently any effort to hack/redesign the Parser to accept some new syntax (backwards compatible, of course) to allow for starting a numbered list at any user defined value? And if there isn't such an effort already, then I'd like to give it a try myself (I've looked at the code already and have a pretty good idea on how to do it).

Starting at a user defined value is one solution (which should be fairly simple to implement), but it pretty much defeats the purpose of an ordered list: if you are going to do the numbering by yourself, why not just add 1., 2., etc in front of the correct lines? This is why I would recommend changing the parser in such a way that longer text can be embedded in a <div>, but I suspect this is a rather large challenge. --valhallasw

Jay R. Ashworth

5:20 p.m.

On Fri, Aug 03, 2007 at 05:14:25AM -0700, Paul Grinberg wrote:

...

For example, numbered lists are a perfect solution for procedure documentation. However, oftentimes it is necessary to insert a <pre>, <div>, or even wiki-syntax table between two consecutive steps. In the current wiki implementation, Parser.php restarts the numbered list back at #1 after such an interjection. Am I missing something? Is there a mechanism to embed these (and possible other) non-numbered list items in a numbered list? If there currently isn't a way to do so, then I'd like to see if there is currently any effort to hack/redesign the Parser to accept some new syntax (backwards compatible, of course) to allow for starting a numbered list at any user defined value? And if there isn't such an effort already, then I'd like to give it a try myself (I've looked at the code already and have a pretty good idea on how to do it).

My personal recommendation, if anyone's planning to hack on the parser, would be magic words: __MANUALNUMBER__ and __RESETNUMBER__ What those ought to do should be obvious, I hope. :-) Is it necessary to more finely granularize the RESET command? Should numbered lists be a full-fledged feature? Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

Mark Clements

9:49 p.m.

"Jay R. Ashworth" <jra(a)baylink.com> wrote in message news:20070803152025.GB22408@cgi.jachomes.com...

...

On Fri, Aug 03, 2007 at 05:14:25AM -0700, Paul Grinberg wrote:

Is it necessary to more finely granularize the RESET command? Should numbered lists be a full-fledged feature?

I think it would be useful if it was. Maybe the syntax would be something like this? --------- # A standard list - this is item 1 # This is item 2 - Numbering is automatic, and works as it currently does. Here is some non-list text # This is a new list, and starts at item 1. This behaviour is unchanged. #6# This new syntax tells MW that this is item 6 (regardless of any previous numbering) # This is item 7 Here is some more non-list text #+# This syntax continues previous numbering, so this is item 8 # item 9 # etc. --------- I don't think that would break much (though I haven't checked) and it would be incredibly useful. - Mark Clements (HappyDog)

Simetrical

10:08 p.m.

My thought on this was that it should optionally use similar syntax to tables, like so: {# # Item one Can be arbitrarily long <pre>Lots of weird stuff in here</pre> # Only now do we get to item two, in the same list # Etc. #} Brion has, I believe, vetoed all of the suggestions made here, when they have been made before at various points. The correct solution for now is to just use HTML lists: <ol> <li>Item one Can be arbitrarily long <pre>Lots of weird stuff in here</pre> <li>Only now do we get to item two, in the same list <li>Etc. </ol> (The closing </li> is not necessary, the software adds it automatically. Note that extra <div>s might be necessary until bug 6200 is fixed: http://bugzilla.wikimedia.org/show_bug.cgi?id=6200 )

Paul grinberg

4 Aug 4 Aug

1:42 a.m.

...

I was hoping to keep the syntax as close to the standard wiki numbered list as possible. I was thinking about something like # Item one # Item two <pre>block of data</pre> #{} Restart numbering from last list, so Item 3 {| |} #{4} Start numbering at 4, so Item 4 I realize that there are lots of preferences either way ...

...

Brion has, I believe, vetoed all of the suggestions made here, when they have been made before at various points. The correct solution for now is to just use HTML lists:

Unfortunately, I am new to this list, so I don't know the history of this discussion. Can you please point me at the previous discussion or maybe summarize the key point here? As part of my experience using and maintaining the wiki at my work, I see this as probably the weakest link in the wiki. I'd like to understand the reasoning behind the decisions made thus far. Thanks, gri6507.

Jim Hu

5 Aug 5 Aug

1:05 a.m.

I think this could be done by manipulating the order in which numbered lists are handled relative to template expansion. In which case, you'd use # first item #:{{:arbitrarily long extra stuff}} # second item This may be a bad idea, since it would change current behavior. i.e. if I transclude a page that is a numbered list, it continues the surrounding list and renumbers items below it. But I'm wondering if that is the desired/expected behavior, and if people actually use it. Jim On Aug 3, 2007, at 6:42 PM, Paul grinberg wrote:

...

Brion has, I believe, vetoed all of the suggestions made here, when they have been made before at various points. The correct solution for now is to just use HTML lists:

===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054

Simetrical

7:12 a.m.

On 8/3/07, Paul grinberg <gri6507(a)yahoo.com> wrote:

...

The basic concern is not to complicate wiki markup unnecessarily. There are various WONTFIXed bugs about it at bugzilla.wikimedia.org. On 8/4/07, Jim Hu <jimhu(a)tamu.edu> wrote:

...

Templates are always substituted before any other wikimarkup parsing occurs. Changing that would break everything.

Paul Grinberg

5:41 p.m.

Simetrical <Simetrical+wikilist@...> writes:

...

On 8/3/07, Paul grinberg <gri6507@...> wrote: > Unfortunately, I am new to this list, so I don't know the history of this > discussion. Can you please point me at the previous discussion or maybe > summarize the key point here? As part of my experience using and

maintaining

...

> the wiki at my work, I see this as probably the weakest link in the wiki.

I'd

...

like to understand the reasoning behind the decisions made thus far.

The basic concern is not to complicate wiki markup unnecessarily. There are various WONTFIXed bugs about it at bugzilla.wikimedia.org.

I can understand and appreciate that. Something like what I proposed (changing the parser) would indeed complicate things for everyone, whether or not they like to have this functionality. However, I see a definite usage for this particular option, certainly within our company and apparently elsewhere. Would a better approach be to add a new hook at the top of Parser::doBlockLevels() to allow for a user defined alternate parser for block levels? Something like what happens near the top of EditPage::edit() where function edit() { global $wgOut, $wgUser, $wgRequest, $wgTitle; global $wgEmailConfirmToEdit; if ( ! wfRunHooks( 'AlternateEdit', array( &$this ) ) ) return; ... } Would something like this be more paletable as the mainstream change to the parser?

Magnus Manske

6 Aug 6 Aug

10:06 a.m.

On 8/5/07, Paul Grinberg <gri6507(a)yahoo.com> wrote:

...

Simetrical <Simetrical+wikilist@...> writes:

maintaining

> the wiki at my work, I see this as probably the weakest link in the wiki.

I'd

like to understand the reasoning behind the decisions made thus far.

The basic concern is not to complicate wiki markup unnecessarily. There are various WONTFIXed bugs about it at bugzilla.wikimedia.org.

How about this: Currently, the parser quietly skips lines that have list markup but are otherwise blank. So: # # #three will render as: 1. three The parser could be changed to /not/ do that at the beginning of a list, but increase an internal counter that will then render the above example correctly as: 3. three Secondly, a recursive template could generate dummy # lines, e.g.: {{numberedliststart|5}} would generate five # lines. Magnus

Paul Grinberg

2:06 p.m.

Magnus Manske <magnusmanske@...> writes:

...

How about this: Currently, the parser quietly skips lines that have list markup but are otherwise blank. So: # # #three will render as: 1. three

is this something new? I just tried this on my install of 1.9.3 and it rendered as 1. 2. 3. three

Jim Hu

2:50 p.m.

What if table parsing was modified to treat #: and the like as a newline? Then it would be # item 1 #:{| #:|- #:|data||data||data #:|} #item 2 ##nested item 2.1 ##:{| ##:|- ##:|data||data||data ##:|} Jim On Aug 6, 2007, at 7:06 AM, Paul Grinberg wrote:

...

Magnus Manske <magnusmanske@...> writes:

How about this: Currently, the parser quietly skips lines that have list markup but are otherwise blank. So: # # #three will render as: 1. three

is this something new? I just tried this on my install of 1.9.3 and it rendered as 1. 2. 3. three _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054

Mark Clements

2:53 p.m.

"Magnus Manske" <magnusmanske(a)googlemail.com> wrote in message news:fab0ecb70708060106s1852343cqcd3e63dc5c60e928@mail.gmail.com...

...

It still doesn't solve the main problem of _continuing_ the numbering (rather than starting at a specific number). If you use one of these methods to continue a list, so you end up with 1,2, ....break... 3,4,5 then you get into difficulty when someone adds an item to the first part of the list. You would then get 1,2,3, ....break... 3,4,5 (unless they also remember to renumber all subsequent parts of the list, which imho is an unacceptable requirement). - Mark Clements (HappyDog)

Platonides

5 Aug 5 Aug

10:03 p.m.

Simetrical wrote:

...

On 8/3/07, Paul grinberg wrote:

The basic concern is not to complicate wiki markup unnecessarily. There are various WONTFIXed bugs about it at bugzilla.wikimedia.org.

There's an easy way to allow starting values without adding new syntax to the grammar: Allow wiki-items and html-items to be mixed. So instead of <ol start="5"> <li>A</li> <li>B</li> <li>C</li> <li>D</li> </ol> you can use <ol start="5"> # A # B # C # D </ol> Mixing # and <li> would be undesirable, but not a big problem for the code.

Paul grinberg

10:44 p.m.

Platonides <Platonides@...> writes:

...

Thanks for the suggestion. For the most part, this would be sufficient, except in cases where on step 2.3.1.5 you have a table and the next step should continue counting at 2.3.1.6. With your suggestion, the syntax would have to be #### Text of step 2.3.1.5 {| | a table |} <ol start=2> <ol start=3> <ol start=1> <ol start=6> #### Text of step 2.3.1.6 Also, this method requires the user to know what the numbered list item number was before the interruption so that the user could explicitly specify the next incremental number by hand. One of the things I'm looking for is to not force the users to do so and have the numbering continue on automatically.

Simetrical

11:46 p.m.

On 8/5/07, Paul grinberg <gri6507(a)yahoo.com> wrote:

...

Not if you can mix them more thoroughly than that: #### Text of step 2.3.1.4 <li>Text of step 2.3.1.5 {| | a table |} </li> #### Text of step 2.3.1.6 or #### Text of step 2.3.1.4 ###<li>Text of step 2.3.1.5 {| | a table |} </li> #### Text of step 2.3.1.6 Of course the <li> would have to be either on the previous line, or at the start of a new line, for that to work. And someone has to write it, which is the tricky part. ;) I don't think there's a bug report requesting this, so someone could feel free to open one.

Jim Hu

6 Aug 6 Aug

6:24 a.m.

On Aug 5, 2007, at 12:12 AM, Simetrical wrote:

...

<snip> Templates are always substituted before any other wikimarkup parsing occurs. Changing that would break everything.

That makes sense to me! Has it always been the case? I vaguely recall some time in the past where template substitution and Cite weren't happening in the desired order from the pov of some Cite users.

...

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054

Simetrical

6:34 a.m.

On 8/5/07, Jim Hu <jimhu(a)tamu.edu> wrote:

...

Templates are always substituted before any other wikimarkup parsing occurs. Changing that would break everything.

Well, I fudged that part a bit. ;) Actually it's more correct to say that substitution of parser tags like <ref> happens first; substitution of things in curly braces (other than subst) happens second; and then everything else happens. This way the results of parser tags/templates can be treated as wikisyntax. But they don't have to be, I don't think. Certainly parser functions don't have to output wikitext. Which is why I dodged them in my last post, because I don't know offhand exactly how they work. In any case, as far as I know, templates have output wikitext since their inception.

Jim Hu

6:45 a.m.

On Aug 5, 2007, at 11:34 PM, Simetrical wrote:

...

On 8/5/07, Jim Hu <jimhu(a)tamu.edu> wrote:

Templates are always substituted before any other wikimarkup parsing occurs. Changing that would break everything.

cool. It's what I thought, then, i.e. it's still true that <ref> inside a template/transclusion doesn't trigger Cite? I assume there's a reason why doing parser tags after templates would break something else. Jim

...

In any case, as far as I know, templates have output wikitext since their inception. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l

===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054

Simetrical

6:52 a.m.

On 8/5/07, Jim Hu <jimhu(a)tamu.edu> wrote:

...

I believe that the issue is that everyone agrees they should be done at the same time as templates (or after?), but nobody's actually written the code.

Steve Sanbeg

3 Aug 3 Aug

10:12 p.m.

It is possible to interrupt and resume a list in some cases, but it's a bit awkward, and won't work with wiki table syntax; i.e. #a #b #c <nowiki> </nowiki><div style=border:1px solid><nowiki> </nowiki>this is some text<nowiki> </nowiki></div> #e #f The awkward syntax could be fixed with an extension. It would also be simple to write a list parsing extension, based on modified parser code, that could do things like start at an arbitrary number. either way, it's probably easier to implement it as an extension, rather than adding it to the core parser code. On Fri, 03 Aug 2007 05:14:25 -0700, Paul Grinberg wrote:

...

6107

days inactive

6110

days old

wikitech-l@lists.wikimedia.org

Manage subscription

20 comments

9 participants

tags (0)

participants (9)

Jay R. Ashworth
Jim Hu
Magnus Manske
Mark Clements
Merlijn van Deen
Paul Grinberg
Platonides
Simetrical
Steve Sanbeg