Problem with neovim builtin LSP (NA in position)

[fikovnik]

I'm experiencing a problem while editing R package in neovim using the builtin LSP support. It might be that it is not languageserver problem, but here is what led me to think that it might be a good idea to report it here:

Every few keystrokes I get the following message:

Error executing lua /usr/share/nvim/runtime/lua/vim/lsp/util.lua:165: attempt to compare number with string

which corresponds to the following code in util.lua:

--- Position is a https://microsoft.github.io/language-server-protocol/specifications/specification-current/#position
--- Returns a zero-indexed column, since set_lines() does the conversion to 1-indexed
local function get_line_byte_from_position(bufnr, position)
  ...
  local col = position.character
  -- When on the first character, we can ignore the difference between byte and
  -- character
  if col > 0 then  -- <- HERE is the problem
  ...

Concretely, in those cases col is a string "NA" which has led me to post it here. A quick fix is to add if col == "NA" then return -1 end, which at least silents the message, but I was wondering if some code range could have been propagated wrongly.

[renkun-ken]

Would you like to provide some debug message to show which provider sends NA to the client?

[randy3k]

Sounds like we should make sure to return 0 for NA column position at https://github.com/REditorSupport/languageserver/blob/master/R/document.R#L131

[randy3k]

As a matter of fact, code_point_to_unit does return ~zero~ NA if the code point position is greater than the number of code units in the line. Though I am not sure why it happens at the first place.

[osthomas]

I think I hit the same or a closely related error.

Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/diagnostic.lua:425: attempt to compare string with number                                                                                
stack traceback:                                                                                                                                                                                                    
        /usr/share/nvim/runtime/lua/vim/diagnostic.lua:425: in function 'add'                                                                                                                                       
        /usr/share/nvim/runtime/lua/vim/diagnostic.lua:462: in function 'get_diagnostics'                                                                                                                           
        /usr/share/nvim/runtime/lua/vim/diagnostic.lua:1151: in function 'show'                                                                                                                                     
        /usr/share/nvim/runtime/lua/vim/diagnostic.lua:718: in function 'set'                                                                                                                                       
        /usr/share/nvim/runtime/lua/vim/lsp/diagnostic.lua:206: in function 'handler'                                                                                                                               
        /usr/share/nvim/runtime/lua/vim/lsp.lua:918: in function ''                                                                                                                                                 
        vim/_editor.lua: in function <vim/_editor.lua:0>

It can be reproduced with an empty file test.R and starting to type function() (see attached log).

languageserver.log

I think it happens because because lintr::lint returns an NA position: https://github.com/REditorSupport/languageserver/blob/9f0e29af3d6c8e4e61eb672d9b04d4ec2ca06706/R/diagnostics.R#L87

FWIW, calling lintr::lint on test.R with the content function() throws an error:

lintr::lint("~/test.R")
# Error in rep.int(character, length) : invalid 'times' value

[andyquinterom]

Should this be close due to #565 ?

[randy3k]

Yes, it should be fixed. I am going to submit a new release to CRAN soon.

[milanglacier]

I face the same problem, despite I am writing with Rmd files (R file works fine though). I am using neovim 0.8 (release) editor with R language server on commit a939390.

when writing with rmd files (start with a plain rmd file and when writing inside code chunks, when writing code that will diagnosed as problematic by lintr), it is easy to trigger such error (traceback)

Error executing vim.schedule lua callback: ...r/neovim/0.8.0/share/nvim/runtime/lua/vim/diagnostic.lua:430: attempt to compare string with number
stack traceback:
        ...r/neovim/0.8.0/share/nvim/runtime/lua/vim/diagnostic.lua:430: in function 'add'
        ...r/neovim/0.8.0/share/nvim/runtime/lua/vim/diagnostic.lua:468: in function 'get_diagnostics'
        ...r/neovim/0.8.0/share/nvim/runtime/lua/vim/diagnostic.lua:1158: in function 'show'
        ...r/neovim/0.8.0/share/nvim/runtime/lua/vim/diagnostic.lua:724: in function 'set'
        ...ovim/0.8.0/share/nvim/runtime/lua/vim/lsp/diagnostic.lua:206: in function 'old_callback'
        .../packer/opt/aerial.nvim/lua/aerial/backends/lsp/init.lua:33: in function 'handler'
        ...w/Cellar/neovim/0.8.0/share/nvim/runtime/lua/vim/lsp.lua:1056: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

here is the lines related in vim/diagnostic.lua:430: in function 'add':

  local function add(b, d)
    if not opts.lnum or d.lnum == opts.lnum then
      if clamp and vim.api.nvim_buf_is_loaded(b) then
        local line_count = buf_line_count[b] - 1
        if
          d.lnum > line_count
          or d.end_lnum > line_count
          or d.lnum < 0
          or d.end_lnum < 0
          or d.col < 0 -- line 430 at here
          or d.end_col < 0
        then
          d = vim.deepcopy(d)
          d.lnum = math.max(math.min(d.lnum, line_count), 0)
          d.end_lnum = math.max(math.min(d.end_lnum, line_count), 0)
          d.col = math.max(d.col, 0)
          d.end_col = math.max(d.end_col, 0)
        end
      end
      table.insert(diagnostics, d)
    end
  end

and using lintr solely on the problematic rmd files

lintr::lint("./has-problems.Rmd")
# Error in rep.int(character, length) : invalid 'times' value

yields similar problem for lintr diagnoistics

[fisher-j]

I am having nearly this same error when working with .Rmd's on windows. I have just updated languageserver.

Error executing vim.schedule lua callback: ...m Files\NeoVim\share\nvim\runtime/lua/vim/diagnostic.lua:430: attempt to compare string with number
stack traceback:
        ...m Files\NeoVim\share\nvim\runtime/lua/vim/diagnostic.lua:430: in function 'add'
        ...m Files\NeoVim\share\nvim\runtime/lua/vim/diagnostic.lua:468: in function 'get_diagnostics'
        ...m Files\NeoVim\share\nvim\runtime/lua/vim/diagnostic.lua:1158: in function 'show'
        ...m Files\NeoVim\share\nvim\runtime/lua/vim/diagnostic.lua:724: in function 'set'
        ...les\NeoVim\share\nvim\runtime/lua/vim/lsp/diagnostic.lua:206: in function 'handler'
        c:\Program Files\NeoVim\share\nvim\runtime/lua/vim/lsp.lua:1049: in function 'cb'
        vim/_editor.lua:248: in function <vim/_editor.lua:247>

[milanglacier]

I think you are mistaken abou the scope of the language server and the linter. They work for R code, not Rmarkdown. You can't attach a language server to a buffer of a different language, so the errors would be expected. You need separate buffers that contain only the R code, which is what the quarto-nvim or the quarto/rmarkdown VS Code extensions do behind the scenes.

This is not the case. Because r-language-server supports rmd natively. So does the lintr.

[milanglacier]

with neovim 0.9, I can't reproduce the problem. I guess maybe neovim 0.9 has improved the robustness of error handling.

In fact if you go to the source code of in the latest commit of neovim the function add in the top level of the traceback has been moved to line 396.

stack traceback:
        /opt/local/share/nvim/runtime/lua/vim/diagnostic.lua:431: in function 'add'

[fisher-j]

Still getting this error in Neovim 10

Error executing vim.schedule lua callback: ...m Files\Neovim\share\nvim\runtime/lua/vim/diagnostic.lua:405: attempt to compare string with number
stack traceback:
        ...m Files\Neovim\share\nvim\runtime/lua/vim/diagnostic.lua:405: in function 'add'
        ...m Files\Neovim\share\nvim\runtime/lua/vim/diagnostic.lua:422: in function 'add_all_diags'
        ...m Files\Neovim\share\nvim\runtime/lua/vim/diagnostic.lua:443: in function 'get_diagnostics'
        ...m Files\Neovim\share\nvim\runtime/lua/vim/diagnostic.lua:1201: in function 'show'
        ...m Files\Neovim\share\nvim\runtime/lua/vim/diagnostic.lua:665: in function 'config'
        ...les/Neovim/share/nvim/runtime/lua/vim/lsp/diagnostic.lua:233: in function 'handler'
        C:/Program Files/Neovim/share/nvim/runtime/lua/vim/lsp.lua:1122: in function 'cb'
        vim/_editor.lua:324: in function <vim/_editor.lua:323>

[PMassicotte]

Did anyone get a fix for this? This is poping every 4-5 seconds when working on a qmd file.

[jmbuhr]

One solution is to not attach the R language server directly to the qmd buffer, but use a plain R buffer in the background via https://github.com/quarto-dev/quarto-nvim

[PMassicotte]

Thank you, just figured it out :)

[willtalmadge]

Judging from a previous comment it sounds like this was fixed? What version should I be on to see the fix? I'm hitting this with neovim 0.9.1 and language server 0.3.15 from CRAN

[randy3k]

The fix is included in 0.3.16 which was published a few days ago. Afaik, the binary for Windows and intel macs are released. The binary for silicon Mac may take a few more days. Or we could install it from the source.

[joihci]

I'm also getting same error as fisher-j mentions above on neovim 0.9.4 with R languageserver 0.3.16.