-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
easy::to_string_pretty
doesn't produce pretty results
#192
Comments
I propose that This function will be the public facing one. An internal one will be used when recursing so we can pass in the relevant information from the caller, in addition to the format config. |
We should port the following tests when we do this |
Hello, I've just touched this. Let me state my understanding of the question and see if my understanding is correct. It seems that you don't think the printout of the current structure, such as If my understanding is correct, what is the perfect output format you want? |
I'd say we start with mimicing
We can look to their serde implementation for a starting point for the algorithm: https://github.com/alexcrichton/toml-rs/blob/master/src/ser.rs Without looking to closely
|
Example failure from cargo's test suite
|
Thanks! I ran across this while trying to see if I can switch my code to using I'm wondering if at some point, finer-grained control might be desirable -- perhaps some sort of trait that can control whether a particular table is serialized as inline or standard. e.g. for a |
This means that the same library can parse summaries created by both old and new versions of guppy. We don't use the summary for much anyway, currently. I also looked at switching to `toml_edit`, which has a much better design overall. Unfortunately, I ran into toml-rs/toml#192. It makes sense to switch to `toml_edit` at some point in the future, and I've filed facebookarchive#492 to keep track of that.
That makes sense. A similar thought i had was a way to control sort order (e.g. The main thing is balancing the complexity, whether thats in a user finding what they want and understanding how to use it, implementing the users code on top of the API, or the implementation within the library. At a certain point of proliferation of customization, it seems like it'd be better for someone to walk the data structure and format it manually. I guess another aspect of all of this is finding the answer to what can we do to support people writing that custom formatting. btw guppy looks interesting! In particular, I find the idea of determinator interesting from two angles
|
Oh that's a super interesting idea. I wonder what an API based on
Thank you! Yeah, the determinator is really cool and has proven to work quite well in a large workspace. I think both of the use cases you described make a lot of sense. I haven't seen much demand for it in open source yet but now that you've asked for it, I now have a reason to clean it up and put it out there :) Happy to chat about this in more detail on Discord or some other medium. |
This means that the same library can parse summaries created by both old and new versions of guppy. We don't use the summary for much anyway, currently. I also looked at switching to `toml_edit`, which has a much better design overall. Unfortunately, I ran into toml-rs/toml#192. It makes sense to switch to `toml_edit` at some point in the future, and I've filed facebookarchive#492 to keep track of that.
This means that the same library can parse summaries created by both old and new versions of guppy. We don't use the summary for much anyway, currently. I also looked at switching to `toml_edit`, which has a much better design overall. Unfortunately, I ran into toml-rs/toml#192. It makes sense to switch to `toml_edit` at some point in the future, and I've filed #492 to keep track of that.
This includes porting tests over from `toml-rs` to ensure we match their behavior. We removed the non-pretty case and the customization since those aren't as important for our use case (cargo) and we'll want to iterate on what we want from the API. Our "pretty" is different than `toml-rs` in that we prefer `"` for strings that could be literals but don't need to be literals to avoid escaping. Note: there are some other discrepancies in our "pretty" string handling that should be looked into, like switching to tripple quotes to avoid escaping. Fixes toml-rs#192
This includes porting tests over from `toml-rs` to ensure we match their behavior. We removed the non-pretty case and the customization since those aren't as important for our use case (cargo) and we'll want to iterate on what we want from the API. Our "pretty" is different than `toml-rs` in that we prefer `"` for strings that could be literals but don't need to be literals to avoid escaping. Note: there are some other discrepancies in our "pretty" string handling that should be looked into, like switching to tripple quotes to avoid escaping. Fixes toml-rs#192
This includes porting tests over from `toml-rs` to ensure we match their behavior. We removed the non-pretty case and the customization since those aren't as important for our use case (cargo) and we'll want to iterate on what we want from the API. Our "pretty" is different than `toml-rs` in that we prefer `"` for strings that could be literals but don't need to be literals to avoid escaping. Note: there are some other discrepancies in our "pretty" string handling that should be looked into, like switching to tripple quotes to avoid escaping. Fixes #192
No description provided.
The text was updated successfully, but these errors were encountered: