Rust in otter doesn't work for me

[0atman]

Thank you very much @jmbuhr - very excited about this project, but my main language, Rust, is the only one that doesn't work for me, cruelly!

Environment

• NVIM v0.10.4
• lazyvim.org distro
• I didn't do much configuration:

return {
  "jmbuhr/otter.nvim",
  dependencies = {
    "nvim-treesitter/nvim-treesitter",
  },
  opts = {},
}

And I activate otter in a markdown buffer with this keymap:

local otter = require("otter")
local map = vim.keymap.set
map("n", "<leader>oa", otter.activate, { desc = "Activate Otter in current file" })

I can see in .local/state/nvim/lsp.log that all the language servers except rust-analyzer starts, no rust errors at all...!

I wonder where I could start debugging this?

[jmbuhr]

Depending on your configuration the rust ls may not be started via lspconfig, but rather some filetype specific plugin and the specification of the language server may also want actual files on disk to see. You can experiment with the set_filetype and write_to_disk options of otter (https://github.com/jmbuhr/otter.nvim?tab=readme-ov-file#configure-otter).

[0atman]

Thanks very much @jmbuhr, I'll give that a go!

[0atman]

I'm unsure where best to run the setup, I'm new to lazy, do I pass the setup table into the lazy spec like this:

return {
  "jmbuhr/otter.nvim",
  dependencies = {
    "nvim-treesitter/nvim-treesitter",
  },
  opts = {
      lsp = {
[rest of spec here]

[0atman]

OK, I'm now more sure of that setup. Sadly, twiddling set_filetype and write_to_disk does not seem to get rust lsp working.

Thank you for your help so far - are there logs I could look at to see why it's not starting the lsp?

I'm using lazynvim's default rust extra, which pulls in rustacean.nvim, and this works great in a normal rust project.

[jmbuhr]

Yes, lazy.nvim will pass on what you put in the opts table to the setup function if the plugin has one. And you only need to pass the options that you actually want to change from the defaults, most plugins merge the opts with their defaults.

[jmbuhr]

Interesting, maybe setting the filetype does not trigger ruestacean and they have their own custom trigger. Or another option: the LSPs of some languages only want to start up if it is actually in a project of that language, like e.g. having a cargo.toml file.

[jmbuhr]

Looks like rustacean should just trigger on the rust ft: https://github.com/mrcjkb/rustaceanvim/blob/master/ftplugin/rust.lua

[jmbuhr]

Unless their config.server.auto_attach is not set.

[jmbuhr]

Ah, I looked into it a bit. Rust really doesn't like files that are not part of a project, at least starting the LSP in single file mode is a bit finicky. But there is a a workaround, which also will play nicely with using this in combination with an actual rust project. We make otter write files to disk and declare that file as an example:

# Example

For this file `test.md`.

Create a `Cargo.toml` file with

```toml
[package]
name = "tmp"
version = "0.1.0"
edition = "2021"

[[example]]
name = "example"
path = "./test.md.otter.rs"

[dependencies]
```

We have some rust code in here:

```{rust}
fn main() {
    println!("Hello, world!");
}
```

Rust analyzer is configured using `lspconfig`, but should be similar for rustacean.

`otter.nvim` is configured including

```lua
    opts = {
      buffers = {
        set_filetype = true,
        write_to_disk = true
      }
    }
```

[jmbuhr]

Note: if you want this file to then also be an actual example of your rust project, you can even export the rust code chunks contained in the markdown file with :lua require'otter'.export() and then use test.md.otter.rs as the name.

[jmbuhr]

Thinking about this, I would be open to making the naming scheme of otter files configurable. Does rust analyzer automatically discover e.g. all files in the examples directory of a cargo workspace? If so, we could e.g. always write the otter files for rust there and it would work out of the box (assuming I also consider changing the defaults for settting the filetype and writing to disk).

[0atman]

Oh wow, that did it! Amazing, thank you so much!

Some questions:

1. I have to manually trigger otter now, saving or waiting no longer updates the lsp (perhaps this is how write_to_disk operates?)
2. lsp keys pass through (such as K for definition hover), but after a few changes to the file, a the .otter.rs file is opened in a background buffer, and lsp keys stop working. inline hints continue, which is the important thing, but this seems odd, see this screenshot:
   

[jmbuhr]

hm, looks like the lsp is not properly receiving the change notifications on changes to the otter buffer, though this shouldn't be an issue related to having the file on disk. Nvim sends those automatically when changes happen to a buffer, assuming client and server are properly attached, which keeps the lsp in the know about the state of the buffer. If this somehow gets out of sync, what you describe can happen.

I would expect diagnostics to update on save, if not that's probably a bug.

When you say manually trigger otter, what do you mean by that?

[jmbuhr]

You can test two things already:

• Does the otter buffer get updated when you change the main buffer? You can open it in a split and observe.
• Does the lsp client notify the server (rust analyzer) of said changes in the otter buffer? https://neovim.io/doc/user/lsp.html#LspNotify (otter does not forward the document sync notifications from the main buffer, instead we just modify the otter buffer, which should always send the correct document changed notifications to the attached ls)