Expose xmlTextWriterSetIndent about rust-libxml

[dginev]

Sounds quite reasonable to add, thanks for the request!

[dginev]

Taking a look, the xmlTextWriter API is completely separate from the xmlSave API, so we can't really request indentation cleanly via the SetIndent method, while still using xmlSaveToBuffer.

I think the only viable approach is resorting to their global variable xmlIndentTreeOutput, in combination with setting SaveOptions.format to true. Using a global makes this a little iffy though, but worth taking another look...

[dginev]

Actually, @matthew-nichols-westtel , could you offer an example/test where setting the format flag fails your expectations? A quick snippet from the tests is:

  let doc_str_formatted = doc.to_string_with_options(SaveOptions {
    format: true,
    ..SaveOptions::default()
  });

Which comes out nicely indented over the unformatted.xml test file. I have vague memories that there were a number of fine details in the way libxml handles spacing, but it has been way too long to remember them sharply.

[matthew-nichols-westtel]

If you change the example to be slightly different it doesn't format entirely:

    let parser = Parser { format: ParseFormat::XML };
    let doc = parser.parse_string(r#"<r:root xmlns:h="http://example.com/ns/hello" xmlns:f="http://example.com/ns/farewell" xmlns:r="http://example.com/ns/root"><h:table><h:tr><h:td>col 1</h:td><h:td>col 2</h:td></h:tr> </h:table>
<f:mock><f:doublemock /></f:mock><f:footer><h:table><h:tr><h:td>col 3</h:td><f:footer> nested f</f:footer></h:tr></h:table></f:footer></r:root>"#).unwrap();
    println!("{}", doc.to_string_with_options(SaveOptions{format: true, no_declaration: true, ..Default::default()}));

Aka if there are existing spaces/newlines/etc it doesn't format as expected, this creates

<r:root xmlns:h="http://example.com/ns/hello" xmlns:f="http://example.com/ns/farewell" xmlns:r="http://example.com/ns/root"><h:table><h:tr><h:td>col 1</h:td><h:td>col 2</h:td></h:tr> </h:table>
<f:mock><f:doublemock/></f:mock><f:footer><h:table><h:tr><h:td>col 3</h:td><f:footer> nested f</f:footer></h:tr></h:table></f:footer></r:root>

whereas xmllint --format still creates

<?xml version="1.0"?>
<r:root xmlns:h="http://example.com/ns/hello" xmlns:f="http://example.com/ns/farewell" xmlns:r="http://example.com/ns/root">
  <h:table>
    <h:tr>
      <h:td>col 1</h:td>
      <h:td>col 2</h:td>
    </h:tr>
  </h:table>
  <f:mock>
    <f:doublemock/>
  </f:mock>
  <f:footer>
    <h:table>
      <h:tr>
        <h:td>col 3</h:td>
        <f:footer> nested f</f:footer>
      </h:tr>
    </h:table>
  </f:footer>
</r:root>

[dginev]

Thanks for the example! Will give it another try soon.

[dginev]

Alright, found out the little detail that makes xmllint --format work. It sets xmlKeepBlanksDefault(0), immediately, which importantly has effect on parsing the input rather than serializing the output. Once the input spaces are discarded, the regular format serialization (that we already support in the wrapper) indents successfully.

So, defying intuition, in order to get an indented output, a libxml2 user must already prepare that before initializing the parser responsible for manipulating the input. I also have a vague memory that there are good "whitespaces are sometimes meaningful in XML" reasons for doing this.

So maybe we can reframe this issue to:

1. Allow for passing in options to Parser
2. Document how to indent difficult cases.

Not sure we can do much else with the way libxml2 is... Whether we use the xmlsave or xmlwriter serialization API, they both reach the same code path, and both require the blanks to have been discarded as part of parsing the input.

[matthew-nichols-westtel]

That's fine.

Oddly enough I can confirm that

unsafe {
    libxml::bindings::xmlKeepBlanksDefault(0);
}

works with parser.parse_string and not parser.parse_file.

Also looking at the kind of files I'm working with I'd like to keep blank lines that were in the original (much like many code formatters do) though I don't currently know how to achieve that.

[dginev]

Right, the parser code is still in a "minimal viable product" shape, you can't customize it or do anything advanced with it. And as you mention, parse_file even goes out of its way to force the blanks to always be there (code here).

So evolving that to accept some options will allow getting the xmllint behaviour. If you want to do something even better than libxml2's algorithm however, you're probably best off writing your own custom serializer, which may end up less confusing in the long run. The main project I've been porting to Rust which uses libxml2 does exactly that, to ensure it formats the XML exactly per the author's taste (which is what the whitespace considerations largely are).

[matthew-nichols-westtel]

Yeah that's probably what I'll have to do eventually.

Thanks for the help!