CDATA always ends up on its own line, no matter how short it is, when using -xml

[jidanni]

Using -xml why does CDATA always end up on its own line, no matter how short it is?

      <referer>
        <![CDATA[http://landmaps.nlsc.gov.tw]]>
      </referer>

[geoffmcl]

@jidanni yes, because that is how libTidy outputs, pretty prints, xml tags, and special nodes, marked as CDATA types... it has no care about the length of the CDATA text...

In this case the <referer> tag has already been flushed, with newline... so the CDATA must start on its own line...

Maybe see PPrintCDATA... it begins with PCondFlushLineSmart... then it disables wrapping... adds the string "<![CDATA["... then the text... plus close "]]>"... then flush at end...

It seems this would require a new option, and support for a use case, for this to be considered a Feature Request... ie a RFC, with use support... even if it can be achieved in code...

Is that what you are suggesting... or maybe I have answered your why... please explain more, advise?

Certainly do not see the use case yet...

Of course, text is treated differently, if you remove the <![CDATA[ xxx ]]> block encasing...

Look forward to further feedback... thanks...

[jidanni]

Well all I know is many long other nodes stay on one line, while even the shortest CDATA nodes end up on a separate line, making my file twice as long as it used to be. How "tidy" would you call that. And what Internet standard says CDATA nodes are supposed to go on separate lines no matter what? Sounds like a convention cooked up by Tidy. Why don't you go picking on some other random node instead.

[geoffmcl]

@jidanni well, I suppose the tidied results are very untidy, if you do not want the output twice as long as it used to be...

Aside from no harm, maybe better readability, etc, etc... choices cooked up over time... Wow! That's tidy's take...

I repeat, in its long HTML history, to the present time, libTidy is NOT a pure XML tool... but it reads nodes into a tree, and can output that tree... so has an xml mode... but...

As I tried, obviously badly, to explain, in libTidy xml output, tags like <referer> are already flushed, to a newline...

That is, before tidy gets to the next node output, which in this case is a CDATA node... but that is irrelevant... any next node, ie some other random node, would now be on a new line... full stop... done deal...

As indicated, seems would need a new option to do what ever you think tidy should do, in the circumstances... need details of that... specifics...

Look forward to further feedback... thanks...

[jidanni]

I see. I suppose since I needed --indent-cdata yes just to get CDATA indented in the first place, so I assumed CDATA was also getting bullied onto extra lines especially too -- when ah ha, in fact every tag when using -xml is in fact getting bullied! So it seems that simply the same algorithm should be used for HTML and XML here, while leaving the forced newlines after each closing tag an option for both HTML and XML modes.