What do you think of this @pascalkuthe?

I wanted it to be able to quickly build a test-suite that runs the code through its paces. It already found two issues, one is fixed and the other one occurs when doing a unified diff with this input:

        Input {
            before: "\n\nA\n\n\n\n",
            after: "",
            context_len: 4294967295,
        }

With a short runtime and without state I don't think CI is going to find more than the roughest of issues, but in theory the local state could be stored.
Ideally, this is run locally for a couple of hours to be reasonable sure all code features are tested and won't panic.

looks nice good addition I think but we would have to get it to actually pass to merge. The one issue you found is regarding that minimum on the tab_width? That seems like a user error (defining tab width to be 0 is not meaningful). I think that is probably the type of issue fuzzing will find most often which you could argue are mainly documentation issue (maybe could use an assert) and then need a fix in the fuzzer definition (possibly similiar for the huge context width altoguh that one is probably a more realistic usecase). Will try to look at this sometime to try and get it to pass, thanks

Thank you, that's great to hear!

Generally I think it's not desirable for a library to panic even on input that makes no sense. Imagine a usecase where clients pass in user data unchecked. They may at least expect an error, which is usually handled gracefully, but panics are then bringing down the whole application. Either it's prevented by the typesystem, or it must be a runtime error. Maybe this whole category could be called 'numerical safety'.

In any case, I hope you find some to fix the context_len related issue, which in the simplest case could be a capping or rejection. It probably doesn't have to be larger than X, which then would naturally be safe to use even on 32 bit platforms.

If you want me to tackle it that way, please let me know @pascalkuthe .