robchur wrote:

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.

messias+spam wrote:

(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", ... );

^^^

rowan.collins wrote:

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!

messias+spam wrote:

(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.

messias+spam wrote:

step 1: changes regexp of doHeadings() / allows only whitespace after heading

Attached:

robchur wrote:

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.

messias+spam wrote:

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.

messias+spam wrote:

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.

gangleri wrote:

see bug 904: Nonmatched == confuses Section Edit
handling a bug previous bug related to "==Test1"