LSP: Extra newlines are inserted when requesting `"crlf"` in a document with pre-existing unix line endings

[DavisVaughan]

• Open a Unix line ending R file
• Set line-ending = "crlf" in an air.toml
• Save using the LSP

Screen.Recording.2025-04-18.at.1.20.56.PM.mov

I think this line is relevant?

air/crates/lsp/src/documents.rs

Line 64 in dac87ff

// TODO: Handle user requested line ending preference here

I'm not 100% sure what is going on:

• Client opens unix document. Document::new() sets LineIndex's endings to LineEnding::Lf
• Formatting occurs on save. Formatter uses air.toml option and generates a formatted string output with Crlf endings (\r\n)
• replace_all_edit() is called using the original line index and its original stored options, i.e. endings of Lf! A bunch of Indels are generated, with insertions of \r because that is the only difference. It does seem like we keep the \r all the way through this function and send it back to the frontend?

[DavisVaughan]

I think it is possibly an undocumented instance of "Air's fault" due to how VS Code further minimizes edits

microsoft/vscode#15385 (comment)

VS Code will take the text of your edit and replace all \r\n, \n, and \r with the user's EOL of choice before applying the edit:
https://github.com/microsoft/vscode/blob/6d602d0d4f0a82ba158a366deb7ad7685ae96579/src/vs/editor/common/services/editorWebWorker.ts#L255

So it's taking our single \r edit and changing it to \n, and then inserting it, so you get \n\n in the end for each line, which causes it to look bonkers in the video.

Even in the best case scenario, the save would be a no-op because VS Code is going to alter our TextEdit to conform with the editor's EOL setting

---

This mostly does not affect ruff, because they don't minimize their edits as much as we do. In this case they would have determined that a single minimal-ish edit is the whole file - something on the first line changed, and something on the last line changed, so they use the start of the first line and end of the last line as their range.

https://github.com/astral-sh/ruff/blob/fd3fc34a9e5115659c3806f736fef8e7404a9daa/crates/ruff_server/src/edit/replacement.rs#L12

VS Code then takes their text edit which contains full \r\n (rather than partial replacements, like ours) and normalizes those to whatever the pre-existing line ending was (\n in this case). So even though you request line-ending = "cr-lf" in a ruff.toml, VS Code says "but the existing line ending was \n, so im going to transform your edit to match that, sorry"

The equivalent for us would probably be to look at each minimal edit we generate from our diff and expand it to capture the start and end of every line we are going to change (and then merge any overlaps). This sounds like a lot of work, and I honestly like the simpler ruff approach more.

[DavisVaughan]

Interesting rust-analyzer approach: recognize when you are changing line endings and just send the whole file over!
https://github.com/rust-lang/rust-analyzer/blob/16745db3f763b6a1a315a91e8f4191b6a7a9da63/crates/rust-analyzer/src/handlers/request.rs#L2447-L2460

That would probably work for us too. This addition was added after the PR that we modeled our diff algorithm implementation on, so it makes sense that we would have missed it.