KenKundert / nestedtext

Human readable and writable data interchange format
https://nestedtext.org
MIT License
362 stars 13 forks source link

FYI: Highlight.js grammar for NestedText #22

Closed joshgoebel closed 3 years ago

joshgoebel commented 3 years ago

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:

Screen Shot 2021-04-07 at 6 58 31 PM

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.

KenKundert commented 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.

joshgoebel commented 3 years ago

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?

KenKundert commented 3 years ago

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
joshgoebel commented 3 years ago

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?

KenKundert commented 3 years ago

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.

KenKundert commented 3 years ago

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"
}
joshgoebel commented 3 years ago

Well, that would be trivial to add if you go that route.

LewisGaul commented 3 years ago

@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?