Skip to content
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

How to get a non inline toml string from a document #29

Open
HUD-Software opened this issue Jun 12, 2023 · 4 comments
Open

How to get a non inline toml string from a document #29

HUD-Software opened this issue Jun 12, 2023 · 4 comments

Comments

@HUD-Software
Copy link

HUD-Software commented Jun 12, 2023

Considering the following toml file:

[package]
authors = [ "me", "I", "myself" ]
name = "proj"
version = "0.0.1"

[profile]

After loading and saving it with the following code (tomlet 5.1.3):

TomlDocument document = TomlParser.ParseFile("file.toml");
using StreamWriter streamWriter= new("result.toml");
document.ForceNoInline = true; // With or withou this, the result is the same
streamWriter.Write(document.SerializedValue);

The content of result.toml file is inlined:

package = { authors = [ "me", "I", "myself", ], name = "proj", version = "0.0.1" }
profile = {  }

How can we get a non inlined string for a document that is loaded not inlined?

@SamboyCoding
Copy link
Owner

You need to set the ForceNoInline property on the package table itself.

@HUD-Software
Copy link
Author

It could be nice to not inline the table that is loaded not inlined

@SamboyCoding
Copy link
Owner

See the readme. We serialize data in a predictable fashion, and prioritise that over everything else. So it doesn't matter what format the input was in, it gets cleaned up to this standard format on reserialization.

Hopefully with TOML 1.1, or 2.0, whichever they call it, this gets more bearable, because inline tables will be able to have newlines within them.

@levicki
Copy link

levicki commented Jul 30, 2023

@SamboyCoding I am also of the opinion that it should be possible to preserve the original formatting or at least instruct the serializer to emit the same format as the input. Being able to preserve comments if any is also useful.

Rationale is that sometimes config files need to be both deserializable / serializable by an application and human readable / editable. Dropping original formatting by the parser kills this dual use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants