Swap diff for faster-diff

[tmcw]

Refs #4801

The faster-diff module appears to be seriously modeled after the O(ND) difference paper, whereas I'm not sure about the diff implementation. This switches prettier to faster-diff. faster-diff is much faster - around 20x speedup.

But:

• This uses a null byte (\0) as the cursor position. I'm not sure how else to represent the cursor in strings. I wonder, given the strategy undertaken here, whether it wouldn't just be simpler to split the old string at the cursor position?
• It fails on current tests. faster-diff behavior doesn't match diff behavior, in subtle ways.

[tmcw]

I'm not seeing a clear route to making faster-diff's behavior exactly match diff's behavior without gutting it - how exactly does this cursor offsetting need to be? Also, any ideas about whether there's some UTF8 character that would be useful as a cursor standin?

[j-f1]

how exactly does this cursor offsetting need to be?

As exact as possible :) Can you run yarn test -u so we can more easily see what the changes are and see how we feel?

Also, any ideas about whether there's some UTF8 character that would be useful as a cursor standin?

Perhaps one of the non-characters?

[j-f1]

After looking through the test failures, it looks like cursor position can differ by parser (according to the current behavior in master). Since this PR improves consistency, I’m feeling better about merging it.

[tmcw]

This fell off the radar for a moment, but I figured out how to update the tests properly - and rebased on master.

[j-f1]

Changes to the output appear reasonable.

[tmcw]

Anything else to fix up so that this is mergable?

[j-f1]

Looks like you’ve got conflicts :/

[vjeux]

We've had very little usage of the cursor preservation code so it's not surprising that it's very slow. The changes are unfortunate but I think it's not the end of the world since they only seem to appear when optional punctuation is being injected, so it's not the end of the world (would be nice if it got fixed though).

Thanks for doing this!

[vjeux]

None of those changes seem right.

thisWillBeFormatted    (2  ,3,  <|> )

If your cursor was after the 3, you don't want it to jump before the 3.

[vjeux]

The cursor was on the line after the 5, you don't want it to become in the same line as the 5

[tmcw]

Is the idea that most editor extensions do their own cursor logic instead of using Prettier's functionality? It looks like the VSCode extension does its own thing, whereas the Atom one uses formatWithCursor.

[duailibe]

Is the idea that most editor extensions do their own cursor logic instead of using Prettier's functionality?

I have no idea. I know I use formatWithCursor in my integration

[tmcw]

Closing in favor of #6164, though it's unclear whether that one'll ever land.