leercontainer-bugzilla wrote:

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.

cyril.cauchois wrote:

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

leercontainer-bugzilla wrote:

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

ccurtis wrote:

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.

c.dittberner wrote:

(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;

c.dittberner wrote:

patch for closing pre-tag on single line

attachment Parser.php.pre_single_line.patch ignored as obsolete

c.dittberner wrote:

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

mediawiki 1.4rc1

jeluf wrote:

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

jeluf wrote:

*** 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
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>

Attached:

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.

zigger wrote:

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

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