xplr plugin experiment

[sayanarijit]

Creating this issue to discuss the possibility and challenges of having xplr as a Zellij plugin.

[sayanarijit]

As of now, I'm stuck at getting let pid = std::process::id(); to work.
I need some ID unique to each xplr session so that I can create the ${runtimedir}/xplr/sessions/${session_pid} directory.
This directory will be used to store runtime files for each particular xplr session.

[sayanarijit]

However, when I execute std::process::id() the process panics with

➜  xplr git:(experiment/zellith) RUST_BACKTRACE=1 zellij -l plugin.yaml
thread 'main' panicked at 'unsupported', library/std/src/sys/wasi/os.rs:222:5
                                                                             note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[TheLostLambda]

Hello @sayanarijit ! The WASI environment is rather sandboxed and quite unaware of the operating system it is running on (by design), so using anything from std::process is probably not going to work very well. If you'd just like a unique id, we can add an API call for that?

If you decide that you definitely need a unique ID, drop a message in #280 and I'll bump that to the top of my priority list!

EDIT: Would it be more useful for you to have the PID of Zellij? Perhaps a combination of the Zellij PID and internal plugin ID?

[sayanarijit]

Hey @TheLostLambda then I guess most of xplrs functionalities won't work since it depends heavily on command invocation. Is it possible to expose an API via which xplr can delegate commands? If yes, would it be possible to also return the status code of the invoked command.?
As for the pid, zellij pid should work fine. The combination will also work if it stays the same across the panes and windows.

[sayanarijit]

Even better if I can get both, id unique to session and panes & windows.

[TheLostLambda]

Can definitely add an API for command delegation! I think the only thing that needs to happen before that is some sort of plugin permissions system (as plugins being able to call arbitrary shell commands is a bit of a security risk). I'll add that to my list!

How would you like a get_id() function that returns a struct like:

ID {
   plugin_id: u32,
   zellij_pid: u32
}

That's something easy enough to knock out in a couple of minutes I think!

[sayanarijit]

@TheLostLambda awesome. That will work.

[TheLostLambda]

@sayanarijit Et voila! It's bizarre, but this simple API addition actually represents a new class of API for plugins. You can call the function anywhere and it just returns the value you're looking for – no update() stuff or Events needed!

We used to have a couple of things like this but moved to the update() and event-bus because we ran into some awful deadlocks. I think as long as these new "query functions" are non-blocking though, this should be fine.

Latest main should have the get_plugin_ids() query function that you need!