I notice that a roundtrip parsing and rendering of the text below in syntax xwiki/2.1 seems to remove the escaped character ~=, hence turning some simple text to a title:
I’d day it’s a bug. It looks to me a bug of the heading parsing since a heading should probably require 2 NLs before it as a standalone element. If this is not correct then it’s an escaping bug.
Actually, I wrote a test in a local checkout of the rendering module, in the syntax 2.0 thing (I hope I wrote it right) and according to that test this:
And of course parsing this back parses it into a heading - which yes, would require 2 NLs, indeed.
The question, to me, is why the initial re-rendering doesn’t render it back escaped, shouldn’t it? I mean shouldn’t it not render wiki syntax at all? or that depends on the context (and in this case the context is considered to be a context where the heading is not valid so it doesn’t need to escape the heading syntax)?
Fix the heading parsing (in the syntax parser) to recognize headings only if there are 2 NLs before it (so that the == doesn’t get parsed as a heading). In this case there’s no need to escape anything in the rendering.
Logically, standalone blocks should require 2 NLs before them, which is why I think it would be better fix but I haven’t thought about all possible consequences yet…
Well, an obvious one is that it would break a lot of existing content so we wouldn’t be able to change that in the current syntaxes (would require a xwiki/2.2 one). Thus for the existing syntax the fix is to fix the missing escape in the rendering.