Last modified: 2011-03-13 18:04:32 UTC
Though it may look nice section headings should not be surrounded by '=', only two to six '=' at the beginning of the line and heading text is only terminated by the line break. This will clear up the syntax, users and planned stream lexers/parsers will benefit from it and it is consistent with other features like lists, indented and pre(formatted) text, it's not embeddable though. <heading> ::= "=" ( <h2> | <h3> | <h4> | <h5> | <h6> ) [<whitespace>] <EOL> <h2> ::= "=" [<whitespace>] <text> <h3> ::= "==" [<whitespace>] <text> <h4> ::= "===" [<whitespace>] <text> <h5> ::= "====" [<whitespace>] <text> <h6> ::= "=====" [<whitespace>] <text> ==Heading 2 ===Heading 3 ====Heading 4 =====Heading 5 ======Heading 6 But this will, of course, break all articles in all MediaWiki installations not only because of the visible trailing equal-signs but also because text is allowed on the same line. I recommend a transitional phase when both markup versions are legal. Scripts can easily insert necessary line breaks and strip trailing equals-signs.
As far as I know, in the current version of the parser, headings are only parsed if they're on their own line; I could be wrong on this, though. Personally, I prefer the enclosing markup, as, I suspect, do others, so we would need to consider just allowing both. What we do want to avoid doing is introducing redundant markup no-one uses.
(In reply to comment #1) > As far as I know, in the current version of the parser, headings are only parsed > if they're on their own line; I could be wrong on this, though. From Parser::doHeading() [Rev 1.504] $text = preg_replace( "/^{$h}(.+){$h}(\\s|$)/m", ... ); ^^^
I don't understand the justification for breaking the current markup; anything on the same line as a heading can safely be considered an error, and ignored by any parser anyone fancies writing, but enclosing the text in matching markup is just fundamentally how it works. If that's a problem for a particular style of future parser, it's going to have a whole lot of problems trying to parse our ''italic'' and '''bold''' markup, so it'll be fighting a losing battle from day one!
(In reply to comment #3) > but enclosing the text in matching markup There's no need for matching markup. You can terminate all headings with double '=' just as well. But when nothing else on the same line is allowed why use '=' at the end at all? Why not let the heading run until EOL is reached? Because it looks nice? > is just fundamentally how it works. No, headings are just like list items and those aren't enclosed either. They all start with a special character and end with the line. > If that's a problem for a particular style of future parser, It's not a problem at all. It's just that shi^H^H^Hpretty grammar bloats the parser.
Created attachment 895 [details] step 1: changes regexp of doHeadings() / allows only whitespace after heading
Altering the markup is going to go against convention. Headings are wrapped in a container object, because that's the sensible thing to do. The container is == == or whatever number of equals signs are required for that particular level of heading. This will have to be implemented as an alternative measure, as we can't reasonably expect people to just give up their old markup. Frankly, the markup you propose is more complicated to the average user, which goes against what this software is all about.
> Altering the markup is going to go against convention. Headings are wrapped in > a container object, because that's the sensible thing to do. [..] the markup > you propose is more complicated to the average user, [..] Carefully! The average user does not think in HTML/XML.
No reason to make incompatible change affecting all pages on all sites with little or no apparent benefit. Resolving WONTFIX.
Though I think people adapt more quickly than you might think, I understand your decision. At least consider applying the small patch. Everyone I spoke to sees text on the same line as headings as an error. Thanks.
see bug 904: Nonmatched == confuses Section Edit handling a bug previous bug related to "==Test1"
