Please provide a better debugging experience (e.g., single-switch tracing)

[ralfbiedert]

Hi, first of all thank you very much for providing this project in your spare time! I am aware my issue is probably not straightforward to address, but since I ran into it a few times now I wanted to file a "user story":

Background

I am using nom in a project of mine. I have spent significant amounts of time trying to debug why parsing something as simple as a text format fails.

It often boils down to small changes of "seemingly correct" macro invocations (joint with surprising combinations that are sometimes not supported, such as combining double_s with CompleteStr, which forces me to resort to more custom hand-written combinations) that consume lots of time to investigate.

I am aware that dbg! macros exist, but their output was often not very helpful for the problems I encountered .

Feature Request

From a user perspective (ideally) I would like to have:

• A single switch (either code, environment, config, or cargo-feature) to enable debugging
• Debugging should provide a trace of both successfully and unsuccessfully parsed elements.
• Successfully parsed elements should be displayed with a clear, step-by-step trace, preferably hierarchically organized, outlining their compositional relationship.
• The final, unsuccessful parse should outline why it could not be matched (i.e., which parsers were tried to be matched against that input).

I can see the "ideal case" might be hard to implement. However, anything that would move nom closer to "one switch debugging" with "more obvious" failure reasons would help me a lot.

[Geal]

that would be interesting, but I don't know yet how I could proceed with this. Maybe by reproducing the ws! combinator's behaviour to intersperse debugging code