I've done similar things in some of the parsers I've worked with. My approach was to include an 'unknown' parser in the code - if it can't correctly parse the code, it decides that it is unknown, and just grabs all of the input up until it can start parsing again. It only works well in places where you know you can get back in sync at a later time.
If Stef wants to use it for Syntax Highlighting, I would assume that he has a place where the user is putting in code (or displaying it), and wants to highlight where the error is. If just the first error is fine, then the existing structure should work - it does raise an error with the location that it couldn't parse beyond. Unfortunately, this is only for the last error it encounters before it gives up - if it was 99% successful on the first option, and 0% successful on the last option, it will give you the error at the end of the last option - meaning the beginning of the code. There is a way to change that (return the most-successful parse tree), but I don't have it handy at the moment.
Almost related to this, I've made a hack on the PPFailure class to return the context of the failure. I got tired of counting character to figure out where the parser was failing - this one returns the code around the failure to give more context. I'm not ready to ask to move it into the main PetitParser code (I've only used it a couple of days so far), but I am willing to share. I've attached a change set with the code, but you'll need to add the context instance variable to PPFailure for it to work (not sure how to add that to a change set), and then install the attached. Feedback is welcome.
Thanks,
Chris