Error E5108: [...] actions.lua: Column value outside range

[rcsalomao]

Hello, When working in python source code, while trying to execute de actions 'append', 'visual', 'yank' and 'fold' it crashes with the following error.

I have been testing and it seems to be related with the "-1" shift on the ["end"].character on the respective function (I think..):

    vim.api.nvim_win_set_cursor(
        display.for_win,
        { display.focus_node.name_range["end"].line, display.focus_node.name_range["end"].character - 1 }
    )

[rcsalomao]

Making some tests, it seems that my LSP (pylsp) or Treesitter is making the scope of the node include the very next line of what it should be the real last line of the node scope. That way, the last character of the scope gets positioned on column 0. display.focus_node.scope["end"].character - 1 -> 0 - 1 -> -1 and then it fails with 'Column outside range'. I don't know if it happens only in python/pylsp or if another LSP shows this behaviour.

[rcsalomao]

Just made a PR ( #56 ) with a fix and refactor to consider cases where the end character gets positioned at column 0.

[SmiteshP]

Making some tests, it seems that my LSP (pylsp) or Treesitter is making the scope of the node include the very next line of what it should be the real last line of the node scope. That way, the last character of the scope gets positioned on column 0.

Not sure I understand the issue 🤔 . Treesitter is out of the question because we are only quering LSP. Can you do one thing? On a same python code snippet, show the difference between pyright's scope values and pylsp's values. You can get these values easily using :lua require"nvim-navic".get_data() when cursor is positioned inside the element.

[rcsalomao]

Alright, I tried executing require"nvim-navic".get_data() but my nvim shows nothing. I must be doing something wrong. Anyway, I installed and used pyright, pylsp and jedi. Both pyright and jedi worked well without issues. Only pylsp ended failing with the column error. To me it seems to be some specific behaviour from pylsp part or my config. Well, I am going to give either pyright or jedi a shot, since those work without issues. Please close the issue and ignore the PR if you would like. Sorry for the inconvenience and thanks a lot!

[SmiteshP]

Ahh my bad! You would need to surround the output from get data in vim.pretty_print :lua vim.pretty_print(require"nvim-navic".get_data())

[rcsalomao]

Ok I was mistaken. jedi-language-server seems to have the same problem, but only for 'for loop scopes'. The interesting part is that jedi-language-server works fine for function and class scopes (just like pyright), but with for loop scopes it fails the same way as pylsp. As far as I know, Python describes scopes only for modules, functions and classes. For loops do not create scopes.

Aditionally, pylsp function and class scopes keep failing. For sake of completeness here is a sample code with pylsp:

Here is the result from comment action for the function scope:

It's possible to see that the next line (fun()) gets commented as well. But it is not from the function scope and when I try to fold it the same column error happens (because the end character seems to be stationed on column 0 of the fun() line).

About the output of the lua command for pylsp:

{ {
    icon = " ",
    kind = 12,
    name = "fun",
    scope = {
      ["end"] = {
        character = 0,
        line = 6
      },
      start = {
        character = 0,
        line = 3
      }
    },
    type = "Function"
  } }

The output for the pyright lsp:

{ {                                                                                                                                                                                            
    icon = " ",
    kind = 12,
    name = "fun",
    scope = {
      ["end"] = {
        character = 19,
        line = 5
      },
      start = {
        character = 0,
        line = 3
      }
    },
    type = "Function"
  } }

It seems those LSPs show different behaviors regarding scopes. That begs the question if it also happens with other languages LSPs as well. I don't know if navbuddy should have some sort of safeguard for those cases? Anyway, I am going to try pyright for a while as it seems to not fail. Feel free to close the issue if you want.