This should be good to go! 🚀

I understand that it's incredibly hard to review, but I'd really appreciate a second look over docs/src/content/addons/contentviews.md and examples/. 😃

For my SAML use case, I wanted my prettify to do things like autoformatting XML text with indentation, which makes it significantly more readable.

However, for editing, I actually wanted to operate on the maybe-deflated and base64-decoded data, because my prettify would break XML signatures.

1. Decode
2. Prettify for UI visualization only
3. edit (on the output of Decode) and re-encode when complete

Is this setup possible with this new feature?

Yes. Here's an example for gRPC/Protobuf: https://asciinema.org/a/MivOWmlDxV3juRNvjhxFU7FH8

With the new API, you can implement:

1. prettify(data: bytes, metadata: Metadata) -> str to implement autoformatting/indentation, and
2. reencode(prettified: str, metadata: Metadata) -> bytes to implement reencoding + signature calculation.

Oh, and you specify syntax_highlighting = "xml" to get syntax highlighting for your use case. :)

Not just syntax highlighting. Adding whitespace and things, which is actually destructive with XML signatures. Any other similar destructive feature is actually nice to do in prettify for better visualization. But, I want an edit feature to run on un-prettifyed text, because prettify may have destroyed data. But I still do want to have decoding (deflate and base64) performed even for edit.

Something like:

• `decode(data: bytes, metadata: Metadata) -> decode binary format for editing only
• prettify(data: bytes, metadata: Metadata) -> str to implement autoformatting/indentation
• reencode(decoded: bytes, metadata: Metadata) -> bytes to implement reencoding. Note: operates on edited decoded bytes, not prettified str

What you have is great for formats that roundtrip through prettify without losing data. Maybe it isn't meant to map exactly to my use case. I guess I could still use this new API by having two contentviews: one for editing that does non-destructive things, and a second that's better for visualization and does prettify aggressively.

But, I want an edit feature to run on un-prettifyed text, because prettify may have destroyed data.

I think this sounds like a very specific use case that may not warrant complicating the API. As you mention, a simple workaround would be to have two separate contentviews here. But more fundamentally, the reencoder could also undo the whitespace changes. That probably not super easy to implement... but feels very much possible. 😃 Let's keep this complexity in the individual contentview, and not in the API that's shared by all contentviews.

For context, while MsgPack reencoding is laughably simple (msgpack.rs#L35-L46), Protobuf is a convoluted dance. I think it's expected that some contentviews are a bit more complex than others.