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.

[HKalbasi]

Glad to see that this is in your roadmap. Would you be open for contributions on this, or do you have a specific design in mind?

[imsnif]

While I appreciate the offer, I have consistently had bad experience with people contributing large features in the past. What almost always happens is that there's a lot of willingness and enthusiasm in the beginning, but as the work continues and time goes by the contributor loses motivation and eventually leaves the feature half-implemented. Forcing me to either change my priorities and finish the work myself, or leave it as is - losing the significant amount of time I put into it.

I'm working on solving this problem by improving the plugin system, giving it more and more capabilities and also slowly moving core Zellij logic into built-in plugins. That way people would be able to work on features - even large features - without this happening.

[HKalbasi]

I understand. I don't think this specific feature is implementable in a plugin, but I see your concern about half backed features and changing the priorities. Even with a complete implementation of the feature, still some priority changes happen as a contributed feature involves reviews and maintenance. So I wouldn't insist, but if you later changed your mind, let me know. I have a relatively good history in pushing large features over finish line in a few open source projects.