`'replacement string' item contains newlines` on reading `.cshtml` files

[kmoschcau]

When I read .cshtml files with either :e or opening a new one after the server has started, I get the following error consistently:

Error executing vim.schedule lua callback: ...l/nvim-data/lazy/rzls.nvim/lua/rzls/virtual_document.lua:76: 'replacement string' item contains newlines
stack traceback:
        [C]: in function 'nvim_buf_set_lines'
        ...l/nvim-data/lazy/rzls.nvim/lua/rzls/virtual_document.lua:76: in function 'update_content'
        ...ocal/nvim-data/lazy/rzls.nvim/lua/rzls/documentstore.lua:118: in function 'update_vbuf'
        ...ocal/nvim-data/lazy/rzls.nvim/lua/rzls/handlers/init.lua:41: in function 'handler'
        ...m Files/Neovim/share/nvim/runtime/lua/vim/lsp/client.lua:1107: in function 'fn'
        vim/_editor.lua:360: in function <vim/_editor.lua:359>

Sometimes with this stack trace instead:

Error executing vim.schedule lua callback: ...l/nvim-data/lazy/rzls.nvim/lua/rzls/virtual_document.lua:76: 'replacement string' item contains newlines
stack traceback:
        [C]: in function 'nvim_buf_set_lines'
        ...l/nvim-data/lazy/rzls.nvim/lua/rzls/virtual_document.lua:76: in function 'update_content'
        ...ocal/nvim-data/lazy/rzls.nvim/lua/rzls/documentstore.lua:118: in function 'update_vbuf'
        ...ocal/nvim-data/lazy/rzls.nvim/lua/rzls/handlers/init.lua:35: in function 'handler'
        ...m Files/Neovim/share/nvim/runtime/lua/vim/lsp/client.lua:1107: in function 'fn'
        vim/_editor.lua:360: in function <vim/_editor.lua:359>
        [builtin#36]: at 0x7ffba7da31c0
        ...a/Local/nvim-data/lazy/rzls.nvim/lua/rzls/server/lsp.lua:79: in function 'request'
        ...m Files/Neovim/share/nvim/runtime/lua/vim/lsp/client.lua:678: in function 'request'
        ...eovim/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:291: in function 'send_request'
        ...eovim/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:640: in function 'start'
        ...m Files/Neovim/share/nvim/runtime/lua/vim/lsp/client.lua:1028: in function <...m Files/Neovim/share/nvim/runtime/lua/vim/lsp/client.lua:1026>

The error sometimes happens multiple times on the same read. It does not seem to happen with .razor files

[tris203]

I suspect, this is going to be to mixed line endings

Are you on windows by any chance?

[kmoschcau]

Yeah this is still on Windows. I have not checked whether it happens on Linux as well. My neovim is also configured to use CRLF and no final newline for cs, cshtml and razor files. It is configured to us le LF and a final newline for everything else. Might be this difference is the cause.

[wambldor]

I debugged a bit and found that __virtual.cs buffers have the file type Unix, but the changes contain “\r\n”. I'm using a Unix operating system.
Furthermore, I created a simple fix locally that recognizes the line endings a bit more pragmatically.

The fix looks something like this:

function detect_line_endings(str)
    if str:match(“\r\n”) then
        return “\r\n”
    elseif str:match(“\n”) then
        return “\n”
    elseif str:match(“\r”) then
        return “\r”
    end
    return “\n”
end

I'll test for a few days how it behaves, and then I can create a fix.

[tris203]

I think the fix needs to go here

https://github.com/tris203/rzls.nvim/blob/main/lua%2Frzls%2Futils%2Finit.lua#L21

The problem with that approach is that string literally will get weird. If you have a string that contains "\r\n" you would get incorrect matches

Edit: It's possibly because the virtual buffers are created with no content, which means they don't auto detect properly

[wambldor]

The problem with that approach is that string literally will get weird. If you have a string that contains "\r\n" you would get incorrect matches

Yes, I've already thought about that, of course it would be best if the virtual buffers had a filetype that matches the content, but they probably come from the language server, right?

[tris203]

The problem with that approach is that string literally will get weird. If you have a string that contains "\r\n" you would get incorrect matches

Yes, I've already thought about that, of course it would be best if the virtual buffers had a filetype that matches the content, but they probably come from the language server, right?

It's generated a blank buffer and then the language server feeds the content in with custom methods

We ideally need to be able to tell Neovim to redetect the line ending (which is normally only done a file open). But I don't think there is an API for that

[kmoschcau]

Wouldn't the 'fileformat' option work for that?

[wambldor]

Wouldn't the 'fileformat' option work for that?

This is currently used, but as I wrote above, the file format of the “virtual.cs” buffers does not match the line breaks actually contained. This causes the error you described.