Multiple neovim support

[TheButlah]

Description

I frequently have many neovim instances open, one for each project in my zellij sessions (like tmux sessions). This means that there will be many running cord.nvim instances.

I noticed that if I start up session A, then do some stuff, then go to session B, session A is still what remains even though it isn't getting any events. It would be awesome if cord.nvim could choose the session that is actually producing events/is being interacted with.

Additional information

No response

[vyfor]

I’ve been thinking of ways to handle this. Right now, each nvim session shows a separate rich presence, with the most recent one displaying on top in Discord (although the web app tends to merge sessions with the same application name). There’s a workaround by hiding the presence when idle and reducing the timeout, which is precisely what you do in your config, but as I mentioned, Discord's rate limits don’t play well if you switch between session too frequently.

One approach I’m considering is splitting the plugin into a client-server setup instead of loading it as a dynamic library via ffi. This way, each nvim session could connect to a single server or act as the host. Or, if it's possible, we might run it separately from nvim entirely, so it can to stay active in the background for a little while before disconnecting from the pipe and closing, again, to stay within Discord’s rate limits. What do you think?

[TheButlah]

I don't really know anything about how discord rich presence works, but that sounds like a reasonable solution.

You could have a WindowsNamedPipe or a unix pipe located someone at a well known name (probably in the nvim data dir), and use that to both detect the server's presence as well as communicate with it

[vyfor]

Hmm, the client/server approach is what I'll likely stick with, as it will also solve #112.

I was considering rewriting the plugin in pure Lua since not everyone has Rust installed, but guess I'll have to put that on hold. I'm unsure how to implement multiple nvim session support in Lua. The above client/server approach is out, so I’d likely need a separate IPC for nvim instances to communicate, with the oldest handling the Discord connection. But then again, nvim lacks proper multithreading, and I wouldn't be able to interact with its API asynchronously in most of the cases, so I might have to call off the whole rewrite thing. I’ll need some time to think this through. Open to suggestions. (Incidentally, the plugin has already been rewritten once from Kotlin Native to Rust 😄)

[TheButlah]

my suggestion about the named pipe/unix pipe was a way to detect and communicate with the server, to avoid spinning up multiple servers. Its more efficient than TCP/UDP and also gives you the ability to have a canonical filepath to identify the existing server (if there is one).

[TheButlah]

I was considering rewriting the plugin in pure Lua since not everyone has Rust installed

Up to you. That being said, you can take the same approach that avante.nvim does: Publish your rust code as a prebuilt artifact, and have a way for people to opt-into builds from source. This ensures that ppl uncomfy with running binaries will have a way to build from source, but everyone else doesn't need rust installed.

[vyfor]

I'm working on the client-server implementation, and it seems like there's quite a bit of work to do. I really like the idea of providing prebuilt artifacts as well.