Problem with the preservation of multi-line basic strings
Hi @maliknajjar Thanks for the update. There seems to be a new problem with the preservation of multi-line basic strings (acc. to https://toml.io/en/v1.0.0#string):
When I add such a string like in this example:
then it is already now displayed in the widget omitting the new lines.
And when I then edit the date (or any other object) using the widgets on the right, then the string is converted to a basic string:
While the content is probably still the same, this seems not to be the behavior that the user wants. Would you agree?
Originally posted by @MoritzRitter in https://github.com/maliknajjar/guifier/issues/5#issuecomment-2385257660
Hi @MoritzRitter, thank you for bringing this up.
The issue you're describing is related to the smol-toml TOML parser that the library uses. The parser should check if a string in the JavaScript object contains newline characters (\n). If it does, the string should be formatted as a multi-line TOML string when converting it back to TOML format.
This behavior should preserve the new lines as expected, instead of converting the string into a basic single-line format.
To be honest, this seems simply out of scope for smol-toml since it's not meant as an editor, only a tool that correctly converts between Javascript data representation and TOML data representation which it does correctly. It's a completely different beast to represent semantically equivalent values differently based on some syntax metadata, especially if you are even gonna change the values without saying anything about the metadata.
How does your GUI itself distinguish single line strings and multiline strings? The problem seems to be that it doesn't only not distinguish them but furthermore you somehow dropped the \n that is actually coming from the library.
@2colours, thanks for your response.
It's a completely different beast to represent semantically equivalent values differently based on some syntax metadata.
got it, so it's not capable of doing that.
How does your GUI itself distinguish between single-line and multi-line strings? The problem seems to be that it not only fails to distinguish them, but also drops the
\nthat's actually coming from the library.
the GUI doesnt distinguish anything. it just parses and stringifies using the smol-toml library. and it wouldn't really matter. Even if the text editor interpreted the \n correctly, it would result in:
multi_line_string = "Line1
Line2
Line3"
which is invalid TOML syntax.
Essentially, it seems there's no way to get the smol-toml library to produce a multi-line string.
@maliknajjar I mean it makes exactly the difference of right and wrong whether the GUI produces separate lines as one long line or not.
It is a bug in guifier that it doesn't escape \n as it should and turns "Line1\nLine2\nLine3" into "Line1
Line2
Line3"
since the smol-toml library doesnt plan on supporting specifying text style in the near future. I will close this for now
I'll just chime in to mention that I've been maintaining a library named toml-patch that would allow to preserve the style of the TOML text data.
Based on my first attempt, it seems like the switch should be relatively simple to do in this project, but if there's anything I can do to help, please let me know.
nice work @DecimalTurn .. your library is really cool if you want. you can create a PR .. I will test it and merge it
Thanks for the kind words, I'm still not sure if I can call it my library since it's a fork, but what is sure is that I'm committed to maintaining it. The JS ecosystem deserves a working package that can preserve comments and formatting in TOML files.
Regarding the PR, I've left it as a draft since I'm not sure if all the possible interactions between the text editor and the GUI are taken care of. Let me know over there if you find any issues.
perfect .. nice to hear that you are committed to maintaining it Ill check it and test asap. thanks 🙏