Restore cursor to same line of code, not same line of buffer

[chmreid]

This updates the way that the new cursor location in the buffer is determined. It is a two-step process. First, all code ahead of the cursor is run through the Black formatter, and the new length of the code ahead of the cursor is determined. This sets the new location of the cursor. Second, the entire buffer is run through Black, as it was previously.

The end result is that the user can call the Black formatter and have the cursor remain on the same line of code as it was before and after the Black formatting process.

To make sure the code ahead of the cursor will pass through the Black formatter okay, we check if the last line ends with : and if so we tack pass onto the end.

This pull request is not very robust to corner cases (yet). For example, if the cursor is located in the middle of a long, multi-line list of arguments.

[ambv]

Thanks! ✨ 🍰 ✨

[ahrex]

Hi @chmreid, I think your PR introduced a few issues:

• sometimes I receive the message EOF in multi-line statement while formatting in the middle of a dictionary
• other times I receive a lot of errors in the middle of a dictionary as well: https://asciinema.org/a/Rkbr8J2CwC0uyOyAWh99vqIfi

I've given it some thought, and I don't know the best way of restoring to the current line without multiple passes.

I also know that trying to reformat half of a python file could result in errors, as demonstrated above. Maybe we can back this out and give it a second try?

[ambv]

Right, I was too hasty in merging this. Let me back this out so @ahrex can land his thing first. Then we can work out the edge cases.

[chmreid]

This pull request is not very robust to corner cases (yet). For example, if the cursor is located in the middle of a long, multi-line list of arguments.

Making this bulletproof/robust to corner cases would, I think, become a quite complicated exercise in parsing Python syntax and I'm not convinced it is worth it