I agree with limiting the scope to the None bug and the faulty call.  However, we should think of the None fix as primary, and the new test thereof as the primary test.  Fixing the None check exposes the call bug, which we also fix.  I change the title here and on PR.

As you noted, the new editor TestCase is not directly relevant to testing the double fix except to show that there is no change in indent.  The way to do that is to pass None instead of the in-string function.  I did that (temporarily!) and the test passes, meaning that the indents are the same.  (I do however think some of them are dubious, and I want to mark those cases.)

We could have made editor tests that initially failed by exposing bod as an instance attribute (as we have done before), and including a longer test case for which bod is a positive int.  However, bod should remain local.

As an alternative, for experimentation, I added print(bod).  The values for the patch are 0, None, None, None, None, None, 0, 0, None.  I added '  a\n' to 'Block opener - indents +1 level.' and changed the mark and the 5th 'None' became '4'.

The fact that passing None and _build_char_in_string_func(startatindex) result in the same indents raises the question of whether the call has any benefit in reducing net time after the followup call to get_continuation_type().  Maybe tomorrow I will try to write a good timeit test.

In the meanwhile, to get some idea of how well find_good_parse_start finds good parse starts, I restarted IDLE in a console with the print still added, loaded editor.py, and hit RETURN followed by UNDO, in various places. The first non-zero bod, 812, comes with the cursor at the end of 'def _sphinx_version():'  812 is probably the beginning of the line.  After "if __name__ == '__main__':" near the end, 1416.  After the final "run(_editor_window)", 1654.  The highest value I got in about 10 tries past the middle, 1931.  To me, this is pathetically bad.

I tried turning on CodeContext and got the same results where I tested.  bod should just be the beginning of the last context line.  I am not optimistic about timing results.