lookahead_not() not matching correctly for non-trivial combinators

[dashbitco]

lookahead_not() not matching correctly for non-trivial combinators

[josevalim]

This is behaving as expected. When you say "the next input should not be ascii_string([?A..?Z], min: 1) |> string("/")", there is a completely valid answer for this, which is to just parse "M" or just parse "MI" and so on. All of them will have the minimum of characters you desire and they won't have the trailing "/" at the end, therefore they are all a valid answers for your negative lookahead.

[rawtaz]

I understand what you're saying. It's pretty undefined though - it's equally valid to say that since the combinator given to lookahead_not() does indeed match the upcoming text, the lookadhead_not() should trigger. It would perhaps be a good idea to make a note about the "minimal matching" nature of lookahead_not() in the documentation, if the current way it works is the desired one?

This makes it really hard to parse "free text", i.e. where you can't list all the allowed characters because it would be impractical, but instead would list the few non-allowed characters :)

EDIT: What do you think about adding an option to the lookahead_not() to let us make it "greedy"?

[josevalim]

Note you can do ascii_string(not: ...), so there are other ways to do negation. Most times the best way is to just assert what you want, exactly because lookaheads may get expensive. Docs to clarify the current behaviour are definitely welcome though.

[rawtaz]

Cheers, I will see about other ways to reach the goal and perhaps file a little PR once I get a more complete picture of the situation. Thanks!