Command output is always split on \n, regardless of actual line ending

[jose-elias-alvarez]

#550 revealed that null-ls was using the buffer's fileformat to determine the command's line ending, which isn't a valid assumption. Commands may use input / environment to determine the "correct" line ending, but it's not something we can rely on.

For now, 9265a99 hardcodes \n as the output line ending. We could theoretically hardcode this at the source level, but that's brittle and would require cross-platform testing to determine command behavior.

The best solution I can think of is to determine the correct line ending from the output itself. neovim/neovim#16286 provides an example of how we might do this (I wouldn't want to rely on the internal utility if / when the PR is merged).

[mjlbach]

I've found that (at least in the LSP case), servers can send a mix of \n, \r and \r\n. It's simpler just to sanitize \r\n to \n and then split on \n than to bother trying to detect the line ending.

[jose-elias-alvarez]

I've found that (at least in the LSP case), servers can send a mix of \n, \r and \r\n. It's simpler just to sanitize \r\n to \n and then split on \n than to bother trying to detect the line ending.

Good idea – I think a solution like the one you used for apply_text_edits() makes sense here, too.

[jose-elias-alvarez]

Closed by 069f60f.