Last modified: 2011-03-13 18:04:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5463, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3463 - Change of syntax for section headings
Change of syntax for section headings
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.6.x
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-14 19:26 UTC by messi
Modified: 2011-03-13 18:04 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
step 1: changes regexp of doHeadings() / allows only whitespace after heading (538 bytes, patch)
2005-09-14 23:11 UTC, messi
Details

Description messi 2005-09-14 19:26:34 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.
Comment 1 Rob Church 2005-09-14 19:29:38 UTC
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.
Comment 2 messi 2005-09-14 20:01:47 UTC
(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", ... );
                                      ^^^
Comment 3 Rowan Collins [IMSoP] 2005-09-14 21:08:24 UTC
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!
Comment 4 messi 2005-09-14 22:43:38 UTC
(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.
Comment 5 messi 2005-09-14 23:11:57 UTC
Created attachment 895 [details]
step 1: changes regexp of doHeadings() / allows only whitespace after heading
Comment 6 Rob Church 2005-09-14 23:15:08 UTC
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.
Comment 7 messi 2005-09-14 23:51:37 UTC
> 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.
Comment 8 Brion Vibber 2005-09-14 23:59:22 UTC
No reason to make incompatible change affecting all pages on 
all sites with little or no apparent benefit. Resolving 
WONTFIX.
Comment 9 messi 2005-09-15 10:00:55 UTC
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.
Comment 10 lɛʁi לערי ריינהארט 2005-10-07 17:06:00 UTC
see bug 904: Nonmatched == confuses Section Edit
handling a bug previous bug related to "==Test1"

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links