Reformatting LibGDX JSON code inserts spaces around ':' in string without qoutes

[acanthite1855]

First of all, I'm not sure if it's a bug, or it's just the way LSON works (because I cannot really find a spec for it)
Now to the issue. Say we have the following code:

{
  case1: string:string
  case2: [ string:string ]
  case3: { string:string }
}

If I have code style that sets spaces after : (or before, or both) character, reformatting the code inserts spaces inside strings (respecting the current code style) which in turn looks like this :

{
  case1: string: string
  case2: [ string: string ]
  case3: { string: string }
}

The third case is formatted properly, because in context of object, colon is a separator between property name and value.

The second should remain string:string, because in context of array colon means nothing.

The first one should probably remain as it is. But it is interesting what should it look like, if it was originally written case1:string:string. Probably the most correct answer is it should be considered just as LibGDX JsonReader() considers it (cannot check it at the moment). But currently the plugin highlights case1:string:string as case1 - property string:string - string value.

Also it looks like { } [ ] , characters cause similar issues. Formatter does not consider context the character is written in.

[acanthite1855]

And one final note. In case1 and case2 after space inserted around colon, editor still considers string: string as a whole string

[BlueBoxWare]

That is a bug: the plugin should ideally parse all JSON exactly as JsonReader does, but it currently can't handle : ] } etc characters in unquoted value strings.

I have no idea how to fix that because JsonReader-tokens are context-sensitive. For example a : is allowed in unquoted value strings but not in unquoted keyword strings and a , is allowed in keys but not in unquoted value strings.

I can't reuse JsonReader in my plugin because IntelliJ needs the lexer and parser to be seperate (JsonReader mixes parsing and lexing) and it also needs an incremental lexer.

BTW my current lexer specification (Jflex) is here and the parser specification here.

[BlueBoxWare]

Actually it is fairly straightforward: the lexing of unquoted strings just has to be done in smaller chunks.