marijnh/CodeMirror — pull request #2229 by bollwyvl (2014-02-07 04:19:31+00:00)
Title: Adding JSON-LD mode

Long-time user, first-time contributor... thanks for the great project!

This is a refactor of the mode now in production on the [JSON-LD Playground](http://json-ld.org/playground/index.html). One of the community members suggested I rebase to CM `master` and start the dialog to get this added, as JSON-LD is now a [W3C Recommendation](http://www.w3.org/TR/2014/REC-json-ld-20140116/), and should be stable.

Since JSON was already handled in `javascript.js`, my initial approach was to emulate the typescript sub-mode by patching `tokenString` and `atomicTypes`. The version in this PR goes ahead and just changes the above directly to minimize the total delta... I am open to suggestions as to how to do this better/more efficiently, or in such a way as to minimize the impact on regular javascript.

Some question that may affect the current implementation:

- I have currently made all of the `@keyword` tokens carry the `meta` type... is there a better token type to use, semantically? It could also be that we'll break up the different types into groups i.e. `@context` and `@id` are the "most important", while `@list` and `@set` are `@container` types... any suggestions there?
- Since JSON has so many strings, the initial coloring I was working from differentiated between object property names and strings. This is the reason for the the bit about checking `jsonldMode` in the property tokenizer. However, this wouldn't be necessary if `cm-property` occurred after `cm-string` in the themes: is there a reason why this isn't the case? Property seems more specific than string...

... and for future expansions...

- I am not doing anything to specifically identify URIs, which seems a bit silly, given the whole "linked data" thing: as mentioned above, the `@id` keyword, which signifies either that a property is an URI or an object's URI, is really important. The thinking here is that my initial regex-based approach would ONLY get fully-qualified URIs, and would be somewhat misleading. What would be the best way to a way to allow a hook to actually check strings for being URIs if being used in an authoring tool, while maybe having a configurable default for finding the most common patterns, like `protocol://` and `prefix:`, where a set of prefixes might be known? Is this most appropriate to an addon?

Thanks again!