It actually does touch on this:

Built-in line and column tracking. Any movement across a newline updates the line number, including a backwards seek. getLine and getColumn are always available and both are one-based, which makes decent error messages nearly free.

That doesn't sound like much, but having hand-written plenty of recursive descent parsers, it's most of what you need for good error messages. Just being able to pinpoint where the error occurred is usually 80% of the battle; but keeping track of lines and columns in a hand-written parser is a pain.

Sure, for something like Rust, you need vastly more than that, but parsing is a tiny fraction of what the Rust compiler is doing -- type-checking and borrow checking is much more complicated and much more important.

A tiny library like this is a great fit for something like an INI file parser.

>> Built-in line and column tracking. Any movement across a newline updates the line number, including a backwards seek. getLine and getColumn are always available and both are one-based, which makes decent error messages nearly free.

> That doesn't sound like much, but having hand-written plenty of recursive descent parsers, it's most of what you need for good error messages.

In my experience having access to the appropriate place where the parser failed is necessary but wholly insufficient for good diagnostics.

What I normally do is: only storing the byte position during the parsing itself, and then extracting the line + column when/if displaying an error.

This allows the error report mechanism to be decoupled, and the hot path of the parser has a bit less code to manage.

I don't really agree. Many top-down parsers find an error at an unexpected token. That token is often not the error. Quite often something is missing at that point, or there has been a mistake some way back. Translating e.g. "unexpected semicolon" into "keyword 'if' should be the identifier 'f'" is not easy.