LSP - Formatting - Consider returning entire file text instead of figuring out text differences

[dsherret]

Doing a diff between two strings is hard and there are some open issues with the diffing library denoland/vscode_deno#492 (comment). Instead of doing a diff between the old and new text like so...

text::get_edits(&file_text, &new_text, line_index)

...we may want to consider returning a single "the entire file changed" response unless file_text == old_text (in which case we would say there is no difference). This is what I do in my dprint vscode plugin and I have never noticed any issues.

It might be unnecessary, but we could further improve that by doing a very simple single diff change from the first difference to the last difference (so start at beginning of file, get first character difference, then look from ends and get the last difference, then return a single change for that range).

Thoughts @kitsonk?

[kitsonk]

My thoughts are:

• I would rather fix the issues with the diffing. It isn't only edits to the client that utilise it. It is also required for sending changes to tsc.
• While me might speculate it isn't a performance problem, we have the benchmarking harness for the lsp to "prove" it. We don't have a formatting benchmark ATM, so I would suggest we create one, irrespective of the path. Some large document, like with 5k+ lines, editing in a couple different places, being formatted. While we can't simulate the client applying them, we would at least get an idea of the tradeoffs and potential performance impact of a change.
• While it might not be a big deal for format on save, I suspect it would be a big deal if we ever supported format on paste and format on type.

[razzeee]

Sorry stumbled over this searching for something else. I maintain a lsp implementation for another language and have seen problems with formatter returning complete files.

Right now I actually diff in the lsp to be able to just send that.

The problem with replacing the whole buffer is, that you are more likely to loose cursor and scroll position. I've seen reports of sublime users formatting a file and sublime scrolling down to the end of it for e.g.

[dsherret]

@razzeee that’s a good point and thanks for your input. Although vscode may be able to handle this fine, I never thought about how some other editors might not be able to. I’m going to close this one.