Capturing of expected values is inflexible

[epage]

If you use char parser, nom automatically reports the expected char but many other parsers (e.g. one_of) don't. This leads to the use of alt((char(.), char(.))) in places where a one_of would make more sense / be cleaner.

Ideally, the error reporting would be made more flexible, which will be made more complicated by #1580.

A (very)( rough proposal

• Split out VerboseErrorKind::Char to an enum Value with
  • Token(T)
  • Set(<I as IntoOutput>::Output)
  • Range(T.=T)
  • Next(usize) (how much of the Input is to be included)
  • Descriptor(&'static str) (for more descriptive names)
• Rename FindTokens to TokenPattern to be more explicit in how its used
• Add a TokenPattern::values iterator that returns all of the error reporting Values contained in it
• Add TokenPattern::named that creates a NamedPattern that exclusive returns Descriptor
• Extend the Error trait for adding expected and unexpected "Value"s
• Add Parser::expected and Parser::unexpected combinators to allow a user to set this on any combinator explicitly

Some inspiration is coming from combine

• https://docs.rs/combine/latest/combine/trait.Parser.html#method.expected
• Errors include unprintable or awkwardly printed characters. Marwes/combine#333

[epage]

#1136 might be relevant

[epage]

If you don't mind losing automatic "expected" capturing, then nom-supremes generic Context works well for this. The advantage of combines approach is it gives you a lot of usability out of the box. The downside is that it gives you a performance hit from all of the allocations when you might not need the context and I'm finding human provided context gives better messages than having it inferred from the combinators.

The main problem I'm still running into is when I want a context to apply only to a map_res. I have a key = value pair and I have to insert it into a hash map but error upon duplicate keys. I'd like to apply a context to this that identifies this as a key error but it wraps would apply to the whole expression. I do allow "more specific" and "less specific" contexts (for some kinds) but it would feel brittle to have a context that only applies in certain situations as I need to make sure I have more specific ones in all other contexts.