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