Ansi escape sequence for multi cursor terminals

[HKalbasi]

Currently zellij can detect multiple users attached to it, but it can't detect if there are multiple users behind a single terminal (zellij) attaching to them:

In the image, the top level zellij can detect that two users are behind it, but the nested zellij is not aware.

And the reason is that, this is technically impossible. Each zellij pane is a single terminal so it can have only a single user with a single cursor and focus.

Here is my idea: Zellij will create a standard similar to OSC, for multi user terminals. It should have commands for distinguishing between the mouse and keyboard events of the users (maybe a set current user command from terminal to the app, exact details doesn't matter) and implement it for zellij as both client (app) and server (terminal). In this way, the nested zellij problem will be solved and users can focus on different panes of the nested zellijs.

But nested zellijs are pretty useless and I'm sure nobody is using them. The point of this ansi standard is that with it editors like vim and helix can support it and become multi user, so for example a zellij + helix combo could compete with things like vscode live share. And in far future other multi user terminal providers like tmux, screen, and even the terminal in the vscode live share can follow the lead and implement the terminal part of the standard, so we can have a screen + vim combo as well.

What do you think?

[imsnif]

This is planned as part of the "multiple backends" feature. Maybe not exactly like this, but essentially the end-goal is to allow multiple users to "bring in" their machine as an additional backend when they connect. So that (for examle) one tab can be the machine of user1, a second tab can be the machine of user2, and they each have control of who can read/write/create terminals on their machine.

This feature is an implementation detail of the above - not sure exactly how it'll work, but we'll see what happens when I get to it.

[rockboynton]

But nested zellijs are pretty useless and I'm sure nobody is using them

I use them. For example, I have a workstation desktop that I run zellij on, connected via ssh to my Mac. In that zellij, I want to connect to development assets via ssh, which I then run zellij on. I'll admit this is a niche use case and I hardly would need multi-user in this scenario anyway.

[HKalbasi]

This feature is an implementation detail of the above - not sure exactly how it'll work, but we'll see what happens when I get to it.

I guess there is a misunderstanding here (my bad). This feature is about extending the multiplayer nature of zellij inside of panes. It enables multiplayer mode for terminal editors (something similar to vscode liveshare for vim), multiplayer games in terminal (for example a snake game with 10 players, all using the same keys), multiplayer apps (for example a dashboard that can show each user focus to other users) and pretty much multiplayer mode for every terminal app that is not a simple cli. And it does so while removing a huge load of complexity from the apps, by taking care of synchronization and communication between multiple processes.

The nested zellij case is just a demo, a playground that we can develop the ansi protocol using it. If it has usecases as well, then great, but the main feature I had in my mind was to extend the multiplayer-ness of zellij to the apps like editors and enabling its full power.

[imsnif]

Thanks for the explanation! I totally get it and I don't think there's a misunderstanding. Probably just me rushing my own run-down of things.

I guess what I'm trying to say is: if we imagine the infrastructure needed for Zellij instances to communicate with each other in order to create both multiple backends and proper nested sessions - we will necessarily need to implement the feature you describe. A Zellij instance, either detecting it is nested or being instructed to defer to another instance, will need to tell that other instance (among other things) who are its users and where their cursors are. Examples of other things it will need to communicate are: information about its terminal/plugin panes (are they readable/writeable by other users), information about its own nested backends (because it is conceivable that an instance with multiple backends will itself be connected to another instance), etc.. The best way for this to happen is IMO through the rendering engine - i.e. some sort of ANSI escape code.

I'm not yet sure which ANSI escape code this will be, but I'm definitely in favor of making it public and encouraging its re-use - just like I did with the UI components. There I felt it made more sense to use a DCS due to the potential length of UI component definitions. Not sure what the requirements will be for the aforementioned protocol - I find things tend to become clearer during development.