Rendering question about a list item containing a row starting with an escaped character

Help / Discuss
#1

Hi everyone,

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:

* Item
~= Test

Here’s a demo link on rendering.xwiki.org.

Is there anything wrong with this syntax? Or is it an issue with the rendering module?

#2

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.

1 Like
#3

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:

* Item 1
~=~= Title

gets parsed into

  <list>
    <listItem>
      <word>Item</word>
      <space/>
      <word>1</word>
      <newLine/>
      <specialSymbol>=</specialSymbol>
      <specialSymbol>=</specialSymbol>
      <space/>
      <word>Title</word>
    </listItem>
  </list>

which is what’s expected.

Then, the content above gets rendered back into:

* Item 1
== Title

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)?

#4

I just created [XRENDERING-661] Special symbol on its own line within list item is not rendered correctly from XDOM to xwiki/2.1 - XWiki.org JIRA. Feel free to amend the title or description to make it closer to the actual bug if needed.

#5

There are 2 options to fix the bug:

  • Fix the escaping in the rendering
  • 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…

#6

Just wondering why we expect two new lines before a heading. This test does not seem to expect this, or maybe I’m misunderstanding?

#7

I never said we expect it, quite the opposite, we don’t ATM! And that’s a bug IMO (it’s debatable but other standalone elements require 2 NLs)

1 Like
#8

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.

#9

This needs to be fixed anyway since you could have the same events from a different source.