.INI can't parse newlines

[FrostBird347]

Attempting to load a string containing "\n" will not produce a string containing a newline.

For example:

[Naming]
OldText=Test0
Text=Test1\nTest2
Mode=0

Will read Naming.Text as "Test1\nTest2" instead of

"Test1
Test2"

(which I will be referring to as "Test1␤Test2" from now on)

In addition, attempting to save the string "Test1␤Test2" to Naming.Text will produce this file:

[Naming]
OldText=Test0
Text=Test1
Test2
Mode=0

Not only will any subsequent attempt at reading the value of Naming.Text only return the first line, changing the new string from "Test1␤Test2" to "Test1␤OldText=Test2" will make all subsequent attempts at reading the value of Naming.OldText return "Test2", as long as Naming.Text was stored below Naming.OldText

[JamesBondski]

I would like to try my hands at this..

In the end, adding a "wrong" (=not supported) value to an ini file should not end up corrupting the file. All I'd do would be to make sure that \r and \n are translated to the appropriate characters in the string and upon writing are translated back and add test cases for both reading and writing.

Does that sound alright? I quite like that the library is pretty robust when parsing ini files otherwise, even allowing stuff like ; and = inside of values with some limits. If wanted, support for the more escape characters would be easy to do (https://en.wikipedia.org/wiki/INI_file#Escape_characters).

[aloneguid]

@JamesBondski supporting =, #, etc after first = is great as today I can just paste base64 encoded value into .ini. Basically I can paste anything without worrying about escaping, however as you have noticed newline will break the parser, because it treats each line as a separate entity. I'd suggest escaping anything that can break the line, in both key and value. Please go ahead if you like to fix this.