Wikimedia Bugzilla is closed!

I have confirmed this here:
<http://nn.wikipedia.org/w/wiki.phtml?title=Brukar:Dittaeva/Sandkasse&oldid=2352>.

The way the text is made you solve the problem by writing it like here
<http://nn.wikipedia.org/wiki/Brukar:Dittaeva/Sandkasse>, using a space in as
the first character of a new line, instead of <pre></pre> on the same line as
the description.

(In reply to comment #1)
> I have confirmed this here:
> <http://nn.wikipedia.org/w/wiki.phtml?title=Brukar:Dittaeva/Sandkasse&oldid=2352>.
> The way the text is made you solve the problem by writing it like here
> <http://nn.wikipedia.org/wiki/Brukar:Dittaeva/Sandkasse>, using a space in as
> the first character of a new line, instead of <pre></pre> on the same line as
> the description.

Ok this way, the text is framed, but it is interpreted. I used <pre> in order to see formatting 
characters ; I don't want them to be rendered.

(In reply to comment #2)
> Ok this way, the text is framed, but it is interpreted. I used <pre> in order
to see formatting 
> characters ; I don't want them to be rendered.

True, I didn't notice that. It iterprets and formats the bold and italic text
but not the headers. I think that is also a bug!?

confirmed in HEAD.

Simplier test case:

--[Cut below]-------
* <pre>foo1</pre>
* <pre>bar2</pre>
* another list item
--[Cut above]-------

Confirmed still present in REL1_4 and HEAD.

I think this bug is more generic than what is stated.  Here is the problem I've
found in the latest (2005-02-08) release:

#Item 1<pre>pre1</pre>
#Item 2<pre>pre2</pre>
#Item 3<pre>pre3</pre>
#Item 4<pre>pre4</pre>
#Item 5<pre>pre5</pre>
#Item 6<pre>pre6</pre>

And you can't just add newlines with spaces because it breaks the numbering, so
there is no workaround (that I've been able to find).

(In reply to comment #7)
> I think this bug is more generic than what is stated.  Here is the problem I've
> found in the latest (2005-02-08) release:

That looks exactly like the samples already provided. All list types are processed with the same code, so it would be 
surprising for numbered lists to behave differently from bullet lists here.

(In reply to comment #7)
> I think this bug is more generic than what is stated.  Here is the problem I've
> found in the latest (2005-02-08) release:
> 
> #Item 1<pre>pre1</pre>
> #Item 2<pre>pre2</pre>
> #Item 3<pre>pre3</pre>
> #Item 4<pre>pre4</pre>
> #Item 5<pre>pre5</pre>
> #Item 6<pre>pre6</pre>
> 
> And you can't just add newlines with spaces because it breaks the numbering, so
> there is no workaround (that I've been able to find).

If you look at the parser code in includes/Parser.php there is a handling for a
pre-open tag but no handling if the pre-close tag is in the same line. Something
like this should solve the problem:
old:
$preOpenMatch = preg_match('/<pre/i', $oLine);

new:
$preOpenMatch = preg_match('/<pre(.*)$/i', $oLine,$preOpenMatches );
$preOpenCloseMatch = preg_match('/\s*\/\s*pre\s*>/i', $preOpenMatches[1] );
$preOpenMatch -= $preOpenCloseMatch;

Created attachment 313 [details]
patch for closing pre-tag on single line

Comment on attachment 313 [details]
patch for closing pre-tag on single line

mediawiki 1.4rc1

Notice: Undefined offset: 1 in /var/www-phase3/includes/Parser.php on line 1518
Patch apparently doesn't work when there's no <pre> within the page

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

Probably got a fix for it. Under testing at the momment.

Created attachment 679 [details]
correctly get out of a pre element when using list

* remove a test to find if the parser is in a pre block. This is already done
at the beginning of the foreach.
* correctly get out of pre block when we have </pre>

My patch need review. It passes the parser test but I am not sure
it is the best way to get out of the pre block.
Somewhere above in the code, there must be a point where the pre
block is closed. That's where the patch should occur. Unfortunatly
I haven't been able to find that point :(

Commiting, I haven't found a better way to do it.
Parser test already in cvs.

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

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