I didn't incorporate all the suggestions into the first PR for this so that it could focus on the parameter change and the tests.  `newline_and_indent_event` does a lot, so I want to make sure the tests look good.  I was also going to add tests for the other indent methods (some are called from `newline_and_indent_event`), but, again, wanted to focus on the bug fix.

Oddly enough, I don't know how to show in the tests that the bug fix makes any difference.  Finding a "good parse start" is more about parsing faster, but, as the tests show from running all the tests with the `context_use_ps1` set to True and False, the results are the same.  Of course, with one or two lines of code, they would be because there isn't much text to parse and ignore.  I did have some tests that had longer text to show that `bod` was being calculated, but I wasn't sure if I should include those for the main goal of testing  the newline and indent.

>  Both calls to fgps (editor and hyperparser) pass _build_char_in_string_func(initial_start), which unconditionally returns a function.  So I think we can delete '=None' and the early return, rather than changing the early return condition.

I'd like to address the on another PR that focuses more on refactoring pyparse than this one.

> If fgps never returns 0

It can return 0, separately from None, as some of the tests on this PR show.

> Perhaps separate issue: the 'if use_ps1' statements in editor and hyperparser, and a couple of lines before, is nearly identical, and could be factored into a separate editor method that returns a parser instance ready for analysis.  It could then be tested in isolation.  The method should return a parser instance ready for analysis.

I agree.  The duplicated code is bugging me.  :-)

---------
One addtional note:  I think that all the indent-related methods in EditorWindow can be factored out into their own class.   It will help make EditorWindow a little more manageable.