Include the end column in validation errors

[pimterry]

It would be super useful to be able to get a column range from a validation error, not just the start column that's currently included. We're looking at using fast-xml-parser for validation in the HTTP Toolkit UI to show inline XML errors, and it would be great to be able to put the red squiggly line in the right place.

Right now, the only real option I think is to show the whole line as an error (which is what https://naturalintelligence.github.io/fast-xml-parser/ does - but this isn't great if your XML isn't prettified since it just highlights the whole document) or show just a single character error on the exact column (technically correct, but ugly and hard to spot, so not great UX).

I understand that won't always be available, so we probably have to fall back to marking the whole line, but I think there's quite a few cases where it should be easy to calculate, and even just having it in a few obvious cases would very useful.

[github-actions]

We're glad you find this project helpful. We'll try to address this issue ASAP. You can vist https://solothought.com to know recent features. Don't forget to star this repo.

[amitguptagwl]

@pimterry can you please consider explaining it with an example? Do you mean the whole tag or word or something else?

[pimterry]

Hi @amitguptagwl. It probably depends on the context and the specific error. As one example though, given:

<root>hello</wrong>

Validation returns:

{
    "err": {
        "code": "InvalidTag",
        "msg": "Expected closing tag 'root' (opened in line 1, col 1) instead of closing tag 'wrong'.",
        "line": 1,
        "col": 12
    }
}

Col 12 just points to the < (I think this is one-indexed, yes?). To highlight this in an XML editor, we need to know where to put the red squiggly line and users generally expect the whole bad section to be marked, not just the first character. In this specific case, it would be useful to have something like "endCol": 19 so we can properly highlight the bad tag within the line.

Similarly it would be helpful to get the start & end of a bad attribute, etc. In most cases I imagine the range will be known already (e.g. in the above case, you have parsed to the end of the tag to get the name anyway) but it's just a matter of extracting & exposing that information.

[amitguptagwl]

got you. let me think how and what to implement here. This will take some time.