= Description =

When using {{{action=format&mimetype=something/something}}} wiki.py outputs linebreaks that are supposed to go inside the preformatted area, outside of it. This means that if I have some format where preformatted linebreaks look like <---|\n and non preformatted linebreaks look like <br/> I'm going to end up with invalid markup outside of the pre tags.

There is also the greater problem that other bugs might crop up, since wiki.py clearly thinks it is inside a pre area, while it in reality is not.

== Steps to reproduce ==
## Describe the steps needed to reproduce the bug. If we can't reproduce it, we  probably can't fix it.
 1. Go to MoinMoin/parser/wiki.py line 1123
 1. Change 'self.request.write(self.formatter.linebreak())' to 'self.request.write(self.formatter.text("#CRAP#"))'
 1. open with http://localhost/~mvirkkil/cgi-bin/moin.cgi/SyntaxReference?action=format&mimetype=text/plain
 1. Notice how the #CRAP# markers aren't all inside the PRE areas
 
== Example ==
{{{
#CRAP#
---%<-------------------------------------------------------------------------
#pragma section-numbers off#CRAP##acl All:admin,read,write,delete,revert#CRAP##language en#CRAP#---%<-------------------------------------------------------------------------
}}}
The ----%<---- parts represent start and end tags for preformatted areas in the plaintext version. 

As you can see the first #CRAP# lands outside the preformatted area.

== Details ==
Python 2.4 on debian based Linux. The MoinMoin version is moin--main--1.3--patch-719

== Workaround ==
remove the 
{{{
if self.in_pre:
    self.request.write(self.formatter.linebreak())
}}}
lines.

= Discussion =

It took me some time to understand the problem.
But I think the following is meant:

At some places in wiki.py the code
{{{
  return self._closeP() + self.formatter.preformatted(1)
}}}
is executed, but the preformatted-function has a main effect (return some string) and a side-effect (set the internal in_pre to true).
 Why does the function have a side effect? That would be a bug.
  Actually one could argue which is the main and which is the side-effect.
   Where do you see the side effect? You still have not answered the question.

See above in top-level: One effect is to return some string, another is to set an internal variable.
Maybe I do not completely understand the API, so I'm sorry when I'm wrong.
In my opinion there might be a problem with:
{{{#!python
start = formatter.preformatted(1) + "Beginning:"
end = "At the end" + formatter.preformatted(0)
return start + formatter.something() + end
}}}
At the time of the return statement, the internal ''in_pre'' variable is already reset to 0, so the ''something'' might be formatted wrong.
But since the above is quite bad coding, it shouldn't happen. I just thought that it does happen somewhere and might be the reason for this bug, but now I don't think so anymore. -- FabianKreutz <<DateTime(2005-05-31T07:21:57Z)>>
 At least it is bad design (on both sides) because the  state is tracked at two points and our pseudo-API does not forbid that.

In my opinion this is not a serious problem.
 Sure, it is - for any formatter which may not send whitespace at arbitrary points.

Maybe the problem is caused by setting in_pre earlier before that call.
 Yes, new hunch (e.g. line 814 in parser/wiki.py):
{{{
     self.in_pre = 3
     return self._closeP() + self.formatter.preformatted(1)
}}}
 No, that's also not it, since _closeP depends on ''in_p'' and not on ''in_pre''.


I'm not too sure about this parsing, but apparently on finding a {{{ {{{ }}} the wiki.py parser set's in_pre to 1 first, if there is no parser given (i.e. no sha-bang).
It then comes to the end of the loop (1123 in wiki.py) and outputs a newline with in_pre=1.
In the next loop then in_pre is raised to 3 and the {{{---%<---}}} is outputted.
There are already some TODO comments at the top of the loop concerning the in_pre variable.

I would improve the workaround above a bit by substituting
{{{
if self.in_pre:
}}} with {{{
if self.in_pre > 1:
}}}. -- FabianKreutz <<DateTime(2005-05-31T07:50:56Z)>>

= Plan =
## This part is for Moin``Moin developers:

 * Priority: 
 * Assigned to: ThomasWaldmann
 * Status: fixed in moin--refactor--1.5--patch-18

----

## When the bug is fixed, replace the category to Category MoinMoinBugFixed
## If this is not a bug, replace with Category MoinMoinNoBug
CategoryMoinMoinBugFixed