"Jay R. Ashworth" jra@baylink.com wrote in message news:20070803152025.GB22408@cgi.jachomes.com...

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

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)

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. #}

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.

On 8/3/07, Paul grinberg gri6507@yahoo.com 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.

On 8/4/07, Jim Hu jimhu@tamu.edu wrote:

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.

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

On 8/5/07, Paul Grinberg gri6507@yahoo.com wrote:

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?

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

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

3. three

---

Wikitech-l mailing list Wikitech-l@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 wrote:

On 8/3/07, Paul grinberg 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.

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.

On 8/5/07, Paul grinberg gri6507@yahoo.com wrote:

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

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.

On 8/5/07, Jim Hu jimhu@tamu.edu wrote:

...

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.

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.

On 8/5/07, Jim Hu jimhu@tamu.edu wrote:

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.

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.