whitespace, again

[yoonsikp]

What are your thoughts on further hardening the specification? What part of the spec needs unicode whitespace, or tab characters?

[KenKundert]

Sorry for the long delay before responding. I have been thinking since you submitted this pull request.

I believe the current approach is the right approach. Consider the following example:

key0    : key ends with an ASCII space
key1    : key ends with a tab
key2    : key ends with no-break space
key3    : key ends with thin space
key4    : key ends with half space

Each of the keys look the same, but in fact each ends with a different white-space character as described by the value. Currently this is interpreted by NestedText as equivalent to the following JSON:

{
    "key0": "key ends with an ASCII space",
    "key1": "key ends with a tab",
    "key2": "key ends with no-break space",
    "key3": "key ends with thin space",
    "key4": "key ends with half space"
}

Each of the 5 cases look the same to the user. If we make the change you suggest then each key would be different as all but the first key would end with unicode white space character. I think that would be confusing to the casual user.

If one really wants a key that ends with a unicode white space, then the multiline key is available.

[yoonsikp]

Seems like it is fixed in v3.6.1

[KenKundert]

Thanks Yoonsikp. I know I did not communicate well on this one, but your pull request is directly responsible for the fix.