Last modified: 2010-05-15 15:33:13 UTC
Here is the text I enter in the edit form : * '''Gras''' : <pre> '''Mon texte en gras''' </pre> * ''Italique'' : <pre> ''Mon texte en italique'' </pre> * '''''Gras Italique''''' : <pre> '''''Mon texte en gras italique''''' </pre> * <cite>Police à chasse fixe</cite> : <pre> <cite>Police à chasse fixe</cite> </pre> * Un Titre de niveau 1 : <pre>=== mon titre 1 ===</pre> * Un Titre de niveau 2 : <pre>== mon titre 2 ==</pre> * Un Titre de niveau 3 : <pre>= mon titre 3 =</pre> The 3rd and the 6th line, the * is not replaced by a bullet ; it appears * in the rendered page.
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. ***
