It is in my opinion not feasible to get line numbers because we use a native PHP extension to parse the JSON.

If the JSON syntax itself is invalid, there is nothing we can do. Best case scenario the parser gives the type of error ("Unexpected comma", "Expected closing curly brace" etc.) but a line number is unlikely.

Once the JSON is parsed, the TemplateData validation itself (e.g. sets referring to existing parameters) we have full control over and gives pretty informative errors with the full path to the property.

Unexpected property "params.user.blabla".
Property "params.timestamp.description" is expected to be of type "string|object".

etc.

Presumably this could be done if bug 50169 was implemented, though. :-)

weskaggs wrote:

Displaying the contents of the line at which an error is detected, with a few lines around it for context, would be almost as useful as a line number. Of course the actual error can be a long way off from the point at which a syntax error is detected, but the information would still be helpful. Adding information about the type of error would make it even better. Really any information at all about the nature of the error would be an improvement.

For the moment, you can use TemplateDataEditor to be able to create the <templatedata/> without editing any real JSON.

http://en.wikipedia.org/wiki/User:NicoV/TemplateDataEditor

(In reply to comment #2)

Presumably this could be done if bug 50169 was implemented, though. :-)

Well, in case of bug 50169 (VisualEditor plugin for TemplateData) there would never be a syntax error in the JSON because the user wouldn't be editing it directly. They'd be using a form-like interface to interact with it (VE would generate the JSON which is always valid).

However if the VE plugin would have a raw mode to edit the JSON (e.g. using an Ace surface like Extension:CodeEditor does), we could use its JSHint integration to get inline errors by line/char highlighting (e.g. like in Sublime).

While I agree this is a valid feature request, I'm afraid there isn't much we can do at this point. I tried to annotate the generic error message with what json_last_error_msg() reports. All it says is "Syntax error". 😞 We would need to use another JSON parser to fulfill this feature request. That's unlikely to happen.