`arf` becomes unresponsive after completing with `<C-n>`

[wklimowicz]

I'm not sure where to report this bug, but I think it's to do with R.nvim: let me know if you think it belongs in https://github.com/eitsupi/arf.

Arf is a nifty new R console: while playing around I noticed it freezes up when I do <C-n> in certain scenarios. I've got a minimal example below. I think it's something to do with how R.nvim processes the global environment?

---

min_init.lua:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "https://github.com/folke/lazy.nvim.git",
        "--branch=stable",
        lazypath,
    })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
    {
        'nvim-treesitter/nvim-treesitter',
        lazy = false,
        build = ':TSUpdate'
    },
    {
        "R-nvim/R.nvim",
        lazy = false,
        opts = {
            R_app = "arf",
        }
    }
})

1. Install arf: curl --proto '=https' --tlsv1.2 -LsSf https://github.com/eitsupi/arf/releases/latest/download/arf-console-installer.sh | sh
2. Run nvim -u min_init.lua test.R
3. \rf: confirm arf is working.
4. Type iris$ and press <C-n>. Also works with anything followed by $, e.g. a$.
5. neovim seems to freeze up for half a second, while displaying match in file term://...//59116:arf, then provides the completion list, but thereafter arf isn't responsive.

If I try the example above just running <C-n> on any letter, e.g. a<C-n> it's fine, which is why I suspect something to do with how R.nvim get's the completion for objects from the environment. No idea how to actually debug this though.

EDIT: I can also get this working without doing it on a $: but this requires me to have some database connections set up, so I don't have a minimal example of that.

[jalvesaq]

You can put this in your ~/.Rprofile to see if R.nvim is sending code to R through a TCP connection:

options(nvimcom.verbose = 3)

For example, if you press <LocalLeader>rh over the word "options", you will see on the R Console:

nvimcom Received: [E] nvimcom:::nvim.help('options', 80L)

If nvimcom.verbose is 5, more information will be printed on the R Console.

[wklimowicz]

I get the following. On initial startup:

nvimcom 0.9.86 loaded
  R_LS_DOC_WIDTH: 78.5
  RNVIM_PORT: 10102
  RNVIM_ID: 906296871
  RNVIM_TMPDIR: /dev/shm/R.nvim-wojtek
  RNVIM_COMPLDIR: /home/wojtek/.cache/R.nvim
  R info: {Rversion = '4.5.0', OutDec = '.', prompt = '> ', continue = '+ ', has
_color = false, kitty_wid = '1', wez_pane = '', tmux_pane = ''}

nvimcom_fire()
send_to_nvim [5] {3574669287}: +Lbase,methods,datasets,utils,grDevices,graphics,
stats,nvimcom#
# arf console v0.2.2
# Edit mode: emacs
# R 4.5.0 is ready.
# Type :cmds for meta commands list, Ctrl+D to exit.
nvimcom_uih()
nvimcom_eval_expr: 'nvimcom:::send_nvimcom_info('27475')'
R 4.5.0> 

Works fine for things like \rn:

R 4.5.0> nvim.names(iris)
[1] "Sepal.Length" "Sepal.Width"  "Petal.Length" "Petal.Width"  "Species"     
nvimcom_task()
nvimcom_globalenv_list()
globalenv_list(0) len1 = 0, len2 = 0

When I do iris$<C-n> I get:

R 4.5.0> nvimcom received: E906296871nvimcom:::send_definition('2', '', 'iris$')
                                                                               n
vimcom_fire()
             nvimcom_uih()
                          nvimcom_eval_expr: 'nvimcom:::send_definition('2', '',
 'iris$')'

Freezes for ~10 seconds, then returns:

          send_to_nvim [5] {3574669287}: +N2

after which if I press enter the screen clears and I'm back to a normal.

I'm none the wiser: does this look like something with R.nvim? Or shall I open an issue with arf?

[jalvesaq]

I can almost replicate the issue in regular R.

If I go to Normal mode and press gd, which is mapped to "<cmd>lua vim.lsp.buf.definition()<CR>", I get the freeze for some seconds, then the script in the editor window is replaced with this:

# base::$ (no source available - deparsed)

.Primitive("$")

I can go back to the R script that I was editing with <c-o>. If I press gd again, it quickly goes to the definition of $. So, the delay only happens the first time.

You could check your LSP key bindings. It looks like that <c-n> in Insert mode is triggering the LSP's go-to-definition function.

[PMassicotte]

The gd is expected to be a bit slow on the first call. I will try to improve that.

[wklimowicz]

Thanks both.

You could check your LSP key bindings. It looks like that in Insert mode is triggering the LSP's go-to-definition function.

I suspected something weird there, but this reproduces even with the minimal init.lua I posted originally. Also funnily enough if I do iris$<C-x><C-o> it's instant, and nothing breaks: it's only for <C-n>: would there be anything in the defaults for R.nvim that trigger the definition provider on <C-n>?

It's definitely to do with the definition provider: with this (everything in r_ls enabled except for definition), it works fine:

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "https://github.com/folke/lazy.nvim.git",
        "--branch=stable",
        lazypath,
    })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
    {
        'nvim-treesitter/nvim-treesitter',
        lazy = false,
        build = ':TSUpdate'
    },
    {
        "R-nvim/R.nvim",
        lazy = false,
        opts = {
            R_app = "arf",
            r_ls = {
                completion = true,
                hover = true,
                signature = true,
                implementation = true,
                definition = false, -- with this disabled it works fine
                references = true,
                doc_width = 0,
                fun_data_1 = { "select", "rename", "mutate", "filter" },
                fun_data_2 = { ggplot = { "aes" }, with = { "*" } },
                fun_data_formula = { ggplot = { "facet_wrap", "facet_grid", "vars" } },
                quarto_intel = nil,

            }
        }
    }
})

I think all the LSP's I worked with have had a fairly slow initial gd, it's more that the "definition triggers on <C-n>" behaviour that's more annoying, because I expect that to be quick.

[jalvesaq]

:RMapsDesc lists the key bindings defined by R.nvim, and <c-n> is not defined.

[jalvesaq]

The gd is expected to be a bit slow on the first call. I will try to improve that.

Part of the information that you need may already be cached. The list of all functions from all libraries is always loaded in rnvimserver memory. The list of all objects in the .GlobalEnv is also in rnvimserver memory.

[jalvesaq]

would there be anything in the defaults for R.nvim that trigger the definition provider on ?

R.nvim mappings are defined in lua/r/maps.lua. You can check that there is no result when searching for <c-. We don't use the Ctrl key in any map.

Please, do this commands : nmap <c-n> (for Normal mode) and : imap <c-n> (for Insert mode) to see if <c-n> is mapped to anything in your Neovim configuration.

[wklimowicz]

Please, do this commands : nmap (for Normal mode) and : imap (for Insert mode) to see if is mapped to anything in your Neovim configuration.

"No mapping found" for all of them. It reproduces on the minimal init.lua also. Weird that you don't get the definition provider behaviour on <C-n>: I'm running nvim -u min_init.lua test.R so I don't think it could be anything to do with my config. Maybe something with the neovim version?

nvim --version               
NVIM v0.11.5
Build type: RelWithDebInfo
LuaJIT 2.1.1761727121
Run "nvim -V1 -v" for more info

Also like you mentioned arf is a red herring here, because this reproduces cleanly for me on radian and R too. I just assumed arf because it was the only thing I changed recently, but I forgot about the R.nvim LSP swap over.

[jalvesaq]

I tried your init.lua, but I can't replicate the bug with regular R. In Normal mode, nothing happens after <c-n>. In Insert mode, when the cursor is after iris$, I get the completion of words from the open buffers, including words from R's startup message. This is the expected behavior, as described by :h ins-completion: "completions from 'complete'". As :h 'complete' reveals, the default completion includes words from buffers (loaded, unloaded, and also from other windows) and completion of tags.

[wklimowicz]

In Insert mode, when the cursor is after iris$, I get the completion of words from the open buffers, including words from R's startup message.

No freezing R terminal? I've done a screen recording to show what it looks like on my end: after <C-n> in insert mode I see the diagnostics in the R console, and then it freezes for ~20 seconds. Even the initial display of the word list seems laggy, something which on a tiny buffer like this should be instant.

Screencast.From.2026-03-01.18-12-55.mp4

This is now on master with the latest PR: the freeze duration seems unrelated to the speed up on goto definition from #509: I've tested that out elsewhere and that works great.

Only thing different in min_init.lua is now I'm just using plain R rather than arf/radian.

min_init.lua

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
    vim.fn.system({
        "git",
        "clone",
        "--filter=blob:none",
        "https://github.com/folke/lazy.nvim.git",
        "--branch=stable",
        lazypath,
    })
end
vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
    {
        "nvim-treesitter/nvim-treesitter",
        branch = "main",
        lazy = false,
        build = ":TSUpdate",
        config = function()
            local langs = { "markdown", "markdown_inline", "r", "rnoweb", "yaml", "latex", "csv" }
            require("nvim-treesitter").install(langs)

            vim.api.nvim_create_autocmd("FileType", {
                pattern = langs,
                callback = function()
                    vim.treesitter.start()
                end,
            })
        end,
    },
    {
        "R-nvim/R.nvim",
        lazy = false,
        opts = {
            R_app = "R",
            r_ls = {
                completion = true,
                hover = true,
                signature = true,
                implementation = true,
                definition = true, -- with this disabled it works fine
                references = true,
                doc_width = 0,
                fun_data_1 = { "select", "rename", "mutate", "filter" },
                fun_data_2 = { ggplot = { "aes" }, with = { "*" } },
                fun_data_formula = { ggplot = { "facet_wrap", "facet_grid", "vars" } },
                quarto_intel = nil,

            }
        }
    }
})

[jalvesaq]

The completion that you get at this moment can't come from the first minimal init.lua that you have posted:

R.nvim provides an LSP server, but the completion is not triggered by <c-n> by default. So, something else is enabled.

I tried your init.lua in a test account on my computer (Debian Linux), where I deleted the ~/.config/nvim directory and created a new one only with your init.lua. The only difference is that I deleted the R_app = "arf" option.

[wklimowicz]

Ok this was to do with the neovim version: it is broken on 0.11.6 and 0.11.5, but works on nightly and 0.11.6.1. I am on fedora 42 with 0.11.5. (This is after some trial and error with podman and appimages). What a doozy.

I think this is the PR that addresses it: neovim/neovim#37260.

Thanks for your patience and help with this @jalvesaq!