Error objects should also contain location information

[mrennie]

Consider the following snippet:

{
  "one": 1
  "two": 2
}

If you run parseTree on it, it parses fine (which is cool), but the error that is reported has no other information than the error code. It would be nice if each error also contained the location information so they could be found in source (for example in an editor or IDE).

Information that would be handy to have:

1. the starting offset of the error
2. the length of the bad stuff
3. the column start of the error
4. the line number

[ulrichb]

Hi Martin Aeschlimann (@aeschli),

Offset and length is now part of ParseError. But what about the line number and column?

[aeschli]

PR is welcome!

[ulrichb]

Martin Aeschlimann (@aeschli) Would you prefer a) additional (redundant) members in ParseError ... or b) some utility function (jsonText: string, error: ParserError) => { line: number; column: number }?

I tend to option a (+ making the members of ParseError readonly).

Further: Should the numbers be 0-based (like in the TypeScript-API), or 1-based (like in the majority of similar language-parsing APIs)?