Rust-analyzer as persistent program?

Is there a way to run a rust-analyzer as a persistent program, say within a tmux; and then neovim connects to the running / existing rust-analyzer session ?

The current approach appears to be that neovim starts up a new rust-analyzer session everytime neovim is restarted.

I don't think there is a simple way to do this, you could in theory do it with some wrapper executables around rust-analyzer (I don't think it can currently bind to a socket),

but I imagine you would want to e.g. ensure that a single editor instance is connected to the specific lsp since the protocol is rather stateful I don't think it would work out so well if just tried to e.g. start up rust-analyzer and throw all the vims at it.

Going to quote from your other thread, because it is pretty related,

Having the same finger memory, what I have resorted to doing is just running nvim-tree with nvim-tree I then have 2 windows so :q quits the first window, it then just shows the directory listing.

This has caused some issues with buffer navigation, i.e. if I have multiple buffers and I delete one, I want it to go to the next buffer, rather than the :q behavior of showing the file tree...

While this works for :q, it is kind of annoying if you have multiple buffers open, and want to delte the current one and actually next buffer, e.g. I now using some workaround like the following to go to the next buffer, and then delete the current.

noremap <leader>bd <cmd>lua bdnext()<cr>
function! Bnext()
   let bufnrs = range(1, bufnr("$"))
   call filter(bufnrs, {_, v -> buflisted(v)})
   if bufnr() == max(bufnrs)
       echo "You are at the last buffer"
   else
       bnext
   endif
endfunction

lua <<EOF
function bdnext()
 local buf = vim.api.nvim_get_current_buf()
 vim.api.nvim_command("Bnext")
 vim.api.nvim_buf_delete(buf, {})
end
EOF

Anyhow, for now that is the basic way i've been working around it, making it so that it requires 2 :q's before vim actually exits... I haven't yet managed to make it do that only when an lsp actually gets started up though...

Edit: Also because I don't really want to look at nvim-tree, I have a thing which shrinks that window when focus exists, and enlarges it when focus enters... So you don't actually have to look at it all the time...
But it is kind of nice because it can show which files have errors/diagnostics in the directory tree...

local flex = vim.api.nvim_create_augroup("NVimTreeFlex", {clear = true})
vim.api.nvim_create_autocmd("BufLeave", {
    nested = true,
    callback =
      function()
        if vim.fn.bufname() == 'NvimTree_' .. tostring(vim.fn.tabpagenr()) then
          local nvim_tree = require('nvim-tree')
          local size = nvim_tree.get_config()["view"]["width"]
          nvim_tree.resize(size)
        end
      end,
    group=flex
})
vim.api.nvim_create_autocmd("BufEnter", {
    nested = true,
    callback =
      function()
        if vim.fn.bufname() == 'NvimTree_' .. tostring(vim.fn.tabpagenr()) then
          require('nvim-tree').resize(30)
        end
      end,
    group=flex
})
EOF

then just on BufLeave it resizes it back to whatever size was set in require('nvim-tree').setup()...
Anyhow that is how i've been working around avoiding rust-analyzer startup cost for now...

1 Like

Irrelevant but I want to share my little experience about RA in nvim:

Quite the opposite to you, I often restart (or even close and start, because these two kinds of commands do not
act identically on my computer) RA several times in the same session of nvim to make RA work correctly.
So I do want nvim to shut RA down and connect to a new one, bearing the mildly long time of RA's start-up.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.