Description

As previously documented in ../IndentedHeadings, indented headings broke starting with version 1.3.

The documented work-around is to remove spaces from the beginnings of heading lines. While this does work, it side steps a useful feature that while not a bug, was being used by a number of folks to produce dotted decimal indented style documents.

Also, since the type sizes are often only fractionally different between the heading levels, indentation is often desired as an additional visual signal for a subsection.

Steps to reproduce

Add additional indented Headings with leading white space at the beginning of the line

Example

Indentation is actually a bit sketchy in several places, but here, we see the heading line being ignored.

Starting back at the base (zero) indent

The markup which is shown failing above is: 

Starting back at the base (zero) indent

 === Third Level Heading ===

  Sample text at third level.

  ==== Forth Level Heading ====

  Sample text at 4th level.

Component selection

Details

This Wiki.

Workaround

  1. Patch the code by hand. See Solution below.

  2. There is another option which to me is much easier and doesn't require editing any code (possibly breaking the gui editor)... wrap the section that you want to be indented using  . {{{#!wiki

  3. E.g.

    • This is an indented heading

      Read the source of this page to see complete method.

  4. You can add lots more inside that {{{ but you can't nest further {{{s inside! For that, close off the current comment & indent a new one using the same method.

  5. It seems it doesn't work with the table of contents macro though..

Discussion

Previously, this was handled by claiming that it was an undocumented behavior and that "there is no meaning to indented headings." I take issue with this interpretation as not in keeping with the spirit of wikis, and even being inconsistent with the practice of adopting useful features.

There is precedent to permit an undocumented feature to become part of the WikiMarkup syntax. MoinMoin itself has done this when it adopted the SixSingleQuotes markup feature. (see HelpOnLinking and more pointedly, the source page that it references: SixSingleQuotes)

The SixSingleQuotes article states:

Further, as if to add more reason to indent headings--just look at the TableOfContents! It's indented! So, why should we disallow indented headers?

Plan

Solution

The following code change in two files fixes the ../IndentedHeadings problem and also restores the functionality to the TableOfContentsMacro which was deliberately broken to match the broken ../IndentedHeadings parser bug. (see ../IndentedHeadingInToc.)

.../moin-1.6.1/MoinMoin/parser/text_moin_wiki.py

Explanation

By adding the \s* between the up-carrot and the RegEx group parenthesis, the pattern is allowed to begin with ZERO or more white spaces.

.../moin-1.6.1/MoinMoin/macro/TableOfContents.py

Explanation

As with the text_moin_wiki.py solution, adding the \s* after the up-carrot and the RegEx group parenthesis, permits the TableOfContents macro to detect Indented Headings and render them correctly.

Python Compliation Notes

If you make the above changes to the text_moin_wiki.py parser and the changes to the TableOfContents macro in an actual running MoinMoin installation, be sure to allow your running MoinMoin web server temporary write access to the .../lib/python#.#/MoinMoin/parser and .../lib/python#.#/MoinMoin/macro directories so that the python engine can write out the .pyc file after compiling your updated code.

Comment

This is not a bug.

If you like your headings to have other style, you have to change the CSS - the wiki markup (and the html) just gives the semantics ("this is a first level heading"), not the style.

If you think that the moin heading style is bad, please contribute a better CSS for it.

-- ThomasWaldmann 2008-03-14 13:27:53

Thanks for looking at this one.

I'm not sure I understand your interpretation. The statement that indentation is exclusively the province of CSS seems to be speaking more from an XML view of the world, rather than in keeping with the spirit and intention of wikis where the syntax (particularly the MoinMoin syntax) is supposed to be intuitive.

The logical extension of this XML based reasoning is that all indentation should be handled in CSS. If the desire is to have MoinMoin syntax change from being wiki simple-intuitive syntax to XML, then indented paragraphs should also be handled exclusively in CSS.

Here's the point: if indentation is relegated solely to the realm of CCS, then I would suggest that all indentation in MoinMoin be disabled, because indentation in the current MoinMoin code is horribly broken both in its rendered output and in it's implementation from an XML standpoint without the patch that I wrote here: ../ParagraphBreaksBrokenWhenIndented which turns indented paragraphs back into paragraphs instead of list items

Also note that currently indented tables are broken without my patch.

Specifically, the output HTML markup that is used for indented paragraphs declares indented paragraphs to be list items--that's just plain wrong from an XML standpoint.

Using an XML argument against indented headings is at best weak, and actually completely inconsistent with MoinMoin's heritage and practice.

In thinking about this a bit more, I realized that the author of a given page is allowed to make many decisions about the physical layout of the content. Notably, the #pragma section-numbers on and indentation to represent logical blocks of text. The point is that within XML and within HTML, it is permitted to have headings inside of blockquotes. Those headings are thus rendered in standard HTML as indented blocks with their headings indented.

The equivalent of such recursive markup (paragraphs and headings existing inside a block quote) in XML or HTML is accomplished with plain old indentation in MoinMoin markup.

Now, there is a FeatureRequests/ThemeCssPerPage which would be roughly the equivalent of the #pragma section-numbers on for specifying the particular style sheet used on a given page, but let's look closely at what this really implies for MoinMoin markup syntax. It means that in order to get indented headings like those that used to work in 1.2.4, the user has to be well versed in CSS language, and clever enough to figure out the twisted HTML that the MoinMoin parser is putting out.

Would it work? Sure. Is it in keeping with the fundamental intent of wikis which is to help authors avoid complicated markup? Absolutely NOT.

What I want to know is why there is so much resistance to implementing this relatively simple fix to something that broke in an earlier version of the MoinMoin parser? Heck, I even provided the code, and it's a damn site easier to use than some custom CSS which would currently affect the display of ALL pages within a MoinMoin wiki, rather than just where the author requests indentation.

I know everyone is busy, and the work you've done has been of very high quality--indeed, the 1.6 code rewrite for handling headings actually makes it possible to return this long broken feature. In 1.5, 1.4, and 1.3, fixing indented headings was a deep bug which does not surrender.

Indented headings, and correctly operating indented paragraphs were a solid feature in early MoinMoin, and many of us found them remarkably useful--and used them!

This fix is:

  1. stunningly small (3 bytes in 3 files)
  2. well isolated to those 3 files

  3. doesn't break anything within the MoinMoin wiki

  4. returns a long lost intuitive markup feature
  5. consistent with the ideal of "simple to use markup" that is the cornerstone of wiki

Besides, docbook XML output is already horribly broken for indented paragraphs, so don't make the argument that indented headings are incompatible with docbook, because MoinMoin isn't creating very good docbook output anyway.

So, why dismiss this WORKING solution out of hand--without even trying it?

I guess my fear is that one of the very best Wikis, MoinMoin, seems to be making the same mistake made by too many commercial software houses of chasing features rather than being sure that the code continues to operate without breaking old perfectly valid pages, and insuring quality by aggressively squashing bugs and fixing introduced functional deterioration.

I implore you to not let MoinMoin suffer this fate of accumulating bugs, feature creep, and lack of compatibility.

I strongly urge this change to be incorporated into the next release of the MoinMoin software. --VincentCordrey 2008-04-18 08:53:30

I suggest to cool down a bit on this. :)

This is not about making wiki markup like xml, but about that html should give the semantics and css should give the style nowadays (and "hard formatting" stuff should be avoided).

So if you in general like indented headings (depending on the level), why don't you just submit a css patch for this? That would be easier to use as you just have to care about the heading level, but not about manually indenting it as in the rest of the document (and as on other pages).

Also, we know that the parser/formatter as it is now has some problems, but it is unlikely that this will be touched in the old parser/formatter - it is just too fragile, if you touch something, it (or even something else) breaks.

We'll likely work on a better formatter soon, but not for 1.6.x and not for 1.7.x (already in freeze).

As you seem to have researched and/or heavily used that stuff, how about documenting the wiki markup -> html transformation for all cases of indentation, quoting and nested lists, lists having multiple paragraphs as one item etc. (just use examples)? Of course the input should be as similar to current markup as possible and output has to be valid (x)html. If there is some markup missing, you can just suggest something sane. I guess this would help us doing things when implementing the next generation of parser/formatter.

From that transformation table, unit tests could be implemented, so we can finally make sure the parser/formatter does what we want. :)

-- ThomasWaldmann 2008-04-18 16:24:17

The company that I work at is still uing 1.2.3 [maintainer left and no one has dared take on the upgrade/migration because of the impact of the version diffs on our 80,000 pages). Indented headings are commonplace in our wiki and losing them would be, well, horrific for the existing content.

I can understand the dev's desire to enforce consistent formatting on wiki syntax for all wiki pages (aka 'latex syndrome'; ergo the desire to do it through css), but the parser doesn't seem to support any kind of css that would allow for indented headings (at least I'm looking at the output on my personal 1.8.4 modernized theme and there are no tags that I can reliably use to block indent a heading and it's related content).

Perhaps this should be filed as a request for enhancement (RFE) for the parser? It might also make section editing easier (should that day ever come).

Anyways, I'm happy for the workaround provided in this bug (thank you) and will use it until such a time as a CSS solution is actually viable (because it doesn't appear to be as of 1.8.4). And face it, in a huge page with many, many, many headings, block indenting sections is clean and much easier to read than the monotony of a bunch of non-indented headings.

-- DavidFidler 2009-08-12 15:59:13

CategoryMoinMoinBug

MoinMoin: MoinMoinBugs/IndentedHeadingsRevisited (last edited 2010-01-19 15:43:01 by 194)