Description

Paragraph breaks when indented aren't respected.

Steps to reproduce

Happens in this wiki.

This following sample:

   This is an indented paragraph

   This second indented paragraph should not apear combined with previous line

• This is an indented paragraph This second indented paragraph should not apear combined with previous line

A similar problem exists for adjacent paragraphs at different indention levels. (Not sure if this is the same problem.) They are not merged, but there is not enough whitespace separating them. -- SteveDavison 2006-06-13 18:41:34

 Single-indent paragraph.

  Douple-indent paragraph.

No-indent paragraph.

• Single-indent paragraph.
  • Double-indent paragraph.

No-indent paragraph.

Here is another example showing the problem -- StefanMerten 2006-08-05 21:43:24:

Tests for multi-lined things. A `|` marks the end of a physical line in the source. A $ marks the end of a paragraph.

  * Do multi-line bullet points |
  work again? Yes. $

  What about additional paragraphs? Are |
  they in the body as they should. No :-( :-( |
  Instead they are merged. $

Definition lists had also problems: $

  Topic:: And does this work |
  again? Works better. $

  Do multi-paragraphed topics work? Not really |
  because second paragraph is merged with first one. $

  Another topic::

  This works |
  similary. $

  Yet another::
  May be it works this way? This works. $

  Another test::
  But probably $

  only when there is no following paragraph. $


  Another test::
  But |
  probably $

  only when there |
  is no following paragraph. $

Numbered lists as well.

  1. Numbered lists |
  had also problems with internal |
  linefeeds. They seemed to be resolved. $

  1. Second entry. $

  With an additional para. $

  And yet another. $

  They are all merged :-( . Does anyone |
  '''test''' such stuff at all? I mean this |
  '''breaks''' existing pages! $

  Ah I'm wrong. $

  Only single-lined paragraphs are merged to the previous one. $

  '''This defies |
  __all__ logic!!! $'''


What about |
paragraphs with |
indented paragraphs. $

  Such as this one. $

  This is often used |
  as a comment. $

    So it really should work. $

    It has the same problem |
    with paragraphs |
    getting merged. $

    That's really not funny... $

I mean that can not be true. $

What if write to paragraphs |
straight after each other |
only separated by a blank line. $

  This works. $

  But it doesn't for indented paragraphs... $

Tests for multi-lined things. A | marks the end of a physical line in the source. A $ marks the end of a paragraph.

• Do multi-line bullet points | work again? Yes. $ What about additional paragraphs? Are |

  they in the body as they should. No | Instead they are merged. $

Definition lists had also problems: $

Topic

And does this work | again? Works better. $ Do multi-paragraphed topics work? Not really | because second paragraph is merged with first one. $

Another topic

This works | similary. $

Yet another

May be it works this way? This works. $

Another test

But probably $ only when there is no following paragraph. $

Another test

But | probably $ only when there | is no following paragraph. $

Numbered lists as well.

1. Numbered lists | had also problems with internal | linefeeds. They seemed to be resolved. $
2. Second entry. $ With an additional para. $ And yet another. $

   They are all merged . Does anyone | test such stuff at all? I mean this | breaks existing pages! $ Ah I'm wrong. $ Only single-lined paragraphs are merged to the previous one. $

   This defies | all logic!!! $

What about | paragraphs with | indented paragraphs. $

• Such as this one. $ This is often used | as a comment. $
  • So it really should work. $ It has the same problem | with paragraphs | getting merged. $ That's really not funny... $

I mean that can not be true. $

What if write to paragraphs | straight after each other | only separated by a blank line. $

• This works. $ But it doesn't for indented paragraphs... $

Details

In the mailing list somebody posted a change to wiki.py's _indent_repl function. This removes the 'not' from the if statement. This fixes this problem, but cause Convert Errors when dealing with similar markup using the GUI Mode. See MoinMoinBugs/GUIEditConvertErrorIndented Block

   1    # if not (self.in_li or self.in_dd):
   2    if self.in_li or self.in_dd:

The bug was introduced in 1.5.3 and still exists in 1.5.4. A working patch is:

*** MoinMoin/parser/wiki.py.orig        Sat Aug  5 22:48:35 2006
--- MoinMoin/parser/wiki.py     Sat Aug  5 22:52:49 2006
***************
*** 569,575 ****
              close[0:0] = [self.formatter.table(0)]
              self.in_table = 0
          
-         self.in_list = self.list_types != []
          return ''.join(close) + ''.join(open)
  
  
--- 569,574 ----

This patch effectively makes self.in_list irrelevant. I did not fully understand why self.in_list has been introduced so this may have other unwanted effects. -- StefanMerten 2006-08-05 21:43:24

Workaround

The workaround is to use the " . " markup in front of indented paragraph. Awkward and not user intuitive.

Discussion

I tested this (both my example and Steve's double-indent example) against my other wiki farm, which is 1.5.2 version, and that doesn't have the problem. So, I believe this got introduced in the latest changes to 1.5.3

• Hmmm... My wiki is still using 1.5.2. It is indeed free of the first problem... but it does show the problem I added. In 1.5.2, there is some whitespace between the two indented paragraphs, but only about 1/2 or 1/3 of the normal amount. -- SteveDavison 2006-06-13 18:41:34

There is also the issue, that indentation is created as a list. This is imnsho plain wrong, and now formatters which don't support bulletless lists will look strange. It's also an issue if the output is even remotely semantically meaningful, because usually the writer didn't intend to write a list, but to simply indent it. DocBook is an example of this, where my current formatter creates visually good markup, but semantically using lists to create indentation is plain wrong. -- MikkoVirkkilä 2006-06-14 13:40:34

Proposed Solution

• Proposed Solution section and all sub sections written by VincentCordrey 2008-03-05 03:54:45

The above mention of indented paragraphs being formatted as list items was part of the clue to the answer, and led to a solution.

Background

In the original MoinMoin 1.2.4 parser, indented paragraphs were handled in the old traditional HTML way, namely, an Un-numbered List (ul) (/ul) was used to create an indented block (which had left indent only, rather than a (blockquote) (/blockquote) which indents from both left and right). Inside that Un-numbered List, actual paragraph marks (p) were used to delineate the paragraphs. This scheme worked rather well, and produced the desired effect: indented paragraphs with proper paragraph spacing between them.

In later versions of the MoinMoin parser these paragraphs were changed to be formatted as list items using a CSS style of "list-style-type:none". This created two problems:

1. Paragraph spacing was lost
2. Text started to run together when it shouldn't combining multiple indented paragraphs into one paragraph.

Implementation Details

Returning to paragraphs within an Un-numbered List (ul) (/ul) seems to fix a number of the anomalies shown by the examples above. (Indeed, I actually took the raw text of this page and put it into a MoinMoin 1.6.1 environment and found that this fix seems to fully resolve the issues. The test case provided with the extensive mark-up samples shown above all seemed to display correctly.)

Change to .../parser/text_moin_wiki.py

Here's the rcsdiff on .../parser/text_moin_wiki.py:

> rcsdiff -r1.2 text_moin_wiki.py
===================================================================
RCS file: RCS/text_moin_wiki.py,v
retrieving revision 1.2
diff -r1.2 text_moin_wiki.py
908c908,909
<             result.append(self.formatter.listitem(1, css_class=css_class, style="list-style-type:none"))
---
>             result.append(self.formatter.paragraph(1))
>             # result.append(self.formatter.listitem(1, css_class=css_class, style="list-style-type:none"))

Explanation of Change

The change is made in the _indent_repl() definition:

    def _indent_repl(self, match, groups):
        """Handle pure indentation (no - * 1. markup)."""
        result = []
                                                # ;;;
        #if self.in_li or self.in_dd:
        if not (self.in_li or self.in_dd):
            self._close_item(result)
            self.in_li = 1
            css_class = None
            if self.line_was_empty and not self.first_list_item:
                css_class = 'gap'
            result.append(self.formatter.paragraph(1))
            #result.append(self.formatter.listitem(1, css_class=css_class, style="list-style-type:none
"))
        return ''.join(result)

The intention of this definition is ostensibly to handle things which are NOT list items, thus we change the formatter call to "self.formatter.paragraph(1)" instead of "self.formatter.listitem(1, ..."

Solution Results

As mentioned before, this solution completely solves all of the documented indented list and paragraph anomalies.

There was also another interesting side effect, namely, tables seem to work better, and their edges (the lines between cells) seem to format more reliably. As an added bonus, indented tables are now NOT broken.

I strongly urge this change to be incorporated into the next release of the MoinMoin software. -- VincentCordrey 2008-03-05 03:54:45

Plan

• Priority:
• Assigned to:
• Status:

CategoryMoinMoinBug