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

Serialization of TOML multi line string #55

Open
Vindaar opened this issue Apr 5, 2022 · 2 comments
Open

Serialization of TOML multi line string #55

Vindaar opened this issue Apr 5, 2022 · 2 comments

Comments

@Vindaar
Copy link
Collaborator

Vindaar commented Apr 5, 2022

In the application where I also stumble on the problem to serialize empty TOML arrays, I also have some multi line strings. As far as I understand the TOML standard, a string in a single quotation mark cannot contain newlines.

So locally I've applied a patch like:

basti at void in ~/src/nim/parsetoml ツ git diff
diff --git a/src/parsetoml.nim b/src/parsetoml.nim
index 06d41f1..f8a5a56 100644
--- a/src/parsetoml.nim
+++ b/src/parsetoml.nim
@@ -1510,8 +1510,12 @@ proc toTomlString*(value: TomlValueRef): string =
   of TomlValueKind.Int: $value.intVal
   of TomlValueKind.Float: $value.floatVal
   of TomlValueKind.Bool: $value.boolVal
-  of TomlValueKind.Datetime: $value.dateTimeVal
-  of TomlValueKind.String: "\"" & value.stringVal & "\""
+  of TomlValueKind.Datetime: $value.datetimeVal
+  of TomlValueKind.String:
+    if '\n' in value.stringVal:
+      "'''" & value.stringVal & "\n'''"
+    else:
+      "\"" & value.stringVal & "\""
   of TomlValueKind.Array:
     if value.arrayVal.len == 0:
       "[]"

On the one hand this feels a bit like a hack. But I mainly didn't open a PR for this, because I'm not sure how to decide whether to use a regular multi line string with quotation marks or one with single ticks. In my use case I want the string to be literal anyway.

Any ideas for how to deal with this?

@PMunch
Copy link
Member

PMunch commented Apr 5, 2022

The easiest would probably be to always use the most lenient string representation. But otherwise this seems like a solution that would work. Only problem is that you seem to add an extra newline to the string?

@Vindaar
Copy link
Collaborator Author

Vindaar commented Apr 5, 2022

While that sounds reasonable, isn't it also a question of intent? The user may or may not depend on the escaping mechanism in their data, no?

Only problem is that you seem to add an extra newline to the string?

Ah, yeah. I mainly did that for readability in my output.

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

2 participants