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

1. Go to MoinMoin/parser/wiki.py line 1123
2. Change 'self.request.write(self.formatter.linebreak())' to 'self.request.write(self.formatter.text("#CRAP#"))'

3. open with http://localhost/~mvirkkil/cgi-bin/moin.cgi/SyntaxReference?action=format&mimetype=text/plain

4. 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:

   1 start = formatter.preformatted(1) + "Beginning:"
   2 end = "At the end" + formatter.preformatted(0)
   3 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 2005-05-31 07:21:57

• 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 2005-05-31 07:50:56

Plan

• Priority:

• Assigned to: ThomasWaldmann

• Status: fixed in moin--refactor--1.5--patch-18

CategoryMoinMoinBugFixed