Closed joshgoebel closed 3 years ago
Nice, thank you. Be aware that we are in the throes of making an incompatible change to the language spec in an attempt to make it simpler. We plan to eliminate quoted keys and may replace them with multi-line keys. Both of these are infrequently used features.
We plan to eliminate quoted keys
Which is a great call, I saw that and never even wasted a moments thought on them.
and may replace them with multi-line keys
Is the idea/concept of this documented anywhere?
We have not settled on the syntax for a multi-line key yet, but we are close. My best guess at the moment is that they will look like this:
: this is a multi-line key
: this is the second line of the key
> This is the value
Interesting. What is the use case for keys like that? What does that evaluate to? Is there a space between "key" (1st line) and "this" (2nd)? How would it know if a space was desired or not?
That example maps to
{
"this is a multi-line key\nthis is the second line of the key": "This is the value"
}
We do not see a compelling use case. Adding it is more about completeness. Previously there were limitations on dictionary keys, and those limitations increased when we got rid of quoted keys. With multiline keys there are no limitations. Any string that consists of printing characters can be a key.
You might want to take a look at this issue. It is where the idea first came up.
Oh, and if you wanted a space you would simply add it to the key. Leading and trailing spaces are retained, as are the newlines.:
: this is a multi-line key␣
: this is the second line of the key
> This is the value
which becomes
{
"this is a multi-line key \n this is the second line of the key": "This is the value"
}
Well, that would be trivial to add if you go that route.
@KenKundert I actually think that multi-line key syntax has some nice properties (e.g. each line type still identifiable without the context of surrounding lines), which I'm sure was part of your careful deliberation. The main thing that's strange about it is that the key is appearing after a colon, making it appear like a value at first glance. It's also not based on any existing YAML syntax as far as I'm aware (multi-line strings in NT are precedent for this, but that doesn't necessarily mean adding more syntax that users are unfamiliar with is a good idea).
Anyway, I don't want to derail this issue thread - perhaps you'd consider opening an issue for discussion if you're thinking of adding this feature?
I really like what you all are doing here with the idea of a dead SIMPLE spec... so I'm adding a grammar to Highlight.js:
https://github.com/highlightjs/highlight.js/pull/3114
We're in between major releases right now so it might be a while before it's released, but just thought I'd let you know.