Support json plist format

[grosser]

Is it possile to parse something like this ?

https://raw.github.com/kangax/textmate-js-language-syntax-file/master/JavaScript.plist

[bleything]

Nope. That's not a plist, just some random file with a plist extension.

[patsplat]

Is that a json plist?

On Wed, Oct 5, 2011 at 11:49 AM, Michael Grosser <
[email protected]>wrote:

Is it possile to parse something like this ?

https://raw.github.com/kangax/textmate-js-language-syntax-file/master/JavaScript.plist

Reply to this email directly or view it on GitHub:
#7

Patrick May
+1 (347) 232-5208

[bleything]

That was my initial thought too, but I looked around and couldn't find any official spec for json plists. I think maybe it's something that TextMate has done to encode plists in a friendlier format?

If there's a standard, even if it's emerging, I'd be happy to add support for it. I just want documentation so we don't end up implementing something broken.

[grosser]

I thin kits this:
http://en.wikipedia.org/wiki/Property_list

From the look of it its the same content, just another format

[bleything]

Well, just about any data structure can be turned into a plist. My opinion is that if plutil doesn't speak it, we shouldn't support it.

That said... turns out plutil has a json format now. I can't find any docs, but it should be relatively easy to write tests to verify that we're doing the right thing.

Reopening this request.

[grosser]

i tried this: http://scw.us/iPhone/plutil/plutil.pl
but it did not read or convert this file, how did you do it ?

[bleything]

$ man plutil

:)

[grosser]

also did not work, maybe its outdated on ubuntu...

[bleything]

Ah, ubuntu. plutil is part of OSX. Can't help you on other platforms.

[patsplat]

Don't have any problems with supporting NeXT property lists but it seems a bit esoteric. Parsing and emitting binary and json plists is definitely a desired feature.

[jasonm23]

@bleything FYI that is not "just some random file with a plist extension."

It's a NextStep plist format (aka the original plist format), It is parsable by both plutil and PlistBuddy.

---

• Strings are represented in C literal style: "This is a plist string\n"; simpler, unquoted strings are allowed as long as they consist of alphanumerics and/or these symbols _$+/:.-.

• Binary data are represented as: < [hexadecimal codes in ASCII] >. Spaces and comments between paired hex-codes are ignored.

• Arrays are represented as: ( "1", "2", "3" ). Trailing commas are permitted.

• Dictionaries/Hashes are represented as: { "key" = "value"; ... } The left-hand side must be a string, but it can be unquoted. Key value pairs can be delimited by ; or newline (or both optionally).

• Comments are allowed as: /* This is a comment */ and // as in C

Given that XCode generates these files today and has done since ... well, a long time. (i.e. since it existed)

Being able to parse these is useful.

[jasonm23]

I'd recommend the issue be re-titled correctly, as this is not a JSON format and obviously leads to confusion.

[bleything]

@jasonm23 thanks for the info, but I haven't been involved in this project for many years. I think this is @mattbrictson's call now.

[jasonm23]

@patsplat I assume it's your decision.