Show spans for errors

[judemille]

Right now, ParseError has the scaffolding to render spans, but only renders one caret, since it only takes the offset. It would be nice for it to show the span of the problematic input -- potentially even showing both a span of the actively parsed input, as well as the problematic portion of the input. Now, that second part would require even more effort, but for some parsers, it wouldn't be too much trouble.

One of my parsers handles strings that have maximum lengths (or must be exact lengths, depending on circumstances), and so could easily return a sub-span to indicate the part of the string "past the limit", so to speak.

I don't know how hard this would be to implement, but I would be happy to help.

[epage]

There are multiple layers to this

• Span of token being parsed
• Sub-section that is failing (e.g. a specific date field in a date-time)
• The specific point that it failed

The problem is the first two are grammar/parser/application specific. Except for try_map and verify_map, we also do not know the end of the first two (and even then, we might not be able to infer it correctly from try_map and verify_map).

#96 would add "where to pick parsing back up" which is somewhat like "where does a token end" but not entirely.

I almost feel like we'll need a combinator that captures the start of the input and, on error, runs a parser to find the end of the token, and inject the span of that into the error type. The interface that lets this span get injected into an error could also allow your max length check inject a span.

This doesn't help with multiple levels of tokens but unsure how best to really solve that in a reusable way.

I think this could be easily experimented in application code to help test out the design and then pulled in. Would you be up for trying this out in your parser?

[judemille]

I think this could be easily experimented in application code to help test out the design and then pulled in. Would you be up for trying this out in your parser?

Definitely!

In my grammar, the bounds of tokens being parsed are already well-known, so the spans can easily be made.
If it's something like a maximum-length string, and it's too long, I can report the (zero-indexed) span (n..=m) where n is the maximum length, and m is the actual length.