zellij
zellij copied to clipboard
WIP: Add detach to cli client
I am attempting to add the detach action in the CLI command zellij action detach.
The issue is that by default, the action is executed for the current client. When we execute zellij action, the client is actually the CLI client itself. However, what is desired is to detach from the client in which that command is executed (I hope this is not too confusing).
I have found that the server checks if a client ID was provided, and if not, it uses the client from which the action was sent. https://github.com/zellij-org/zellij/blob/9a38ad2e152b914c75f0156e5a9985fe22013346/zellij-server/src/route.rs#L846
To solve this problem, I check the ZELLIJ_CLIENT_ID environment variable if it is available (although it is not present by default, but that is a separate issue). Now, I can use ZELLIJ_CLIENT_ID=1 zellij action detach and it works as expected.
However, I am unsure if using an environment variable is the desired approach here. If at some point ZELLI_CLIENT_ID or a similar variable is added to the environment, then all actions would be executed against that client. One possible solution would be to add a --client option for the action command and provide the client ID there.
I would appreciate it if someone more familiar with the project could inform me:
- Is the environment variable route a good solution, or should it be a command line option?
- Should the detach action even be added?
Related issue: #1963
PS.
I have also tried to add switch-session, but it has the same issue. It would need to be run against a different client-id, not the cli client id.
Hey, so as I explained in the attached issue - this is the reason we don't have this implemented. It's impossible to tell which client to detach.
I've given this some thought since the issue was opened, and I think I'd be willing to go with the following behavior:
- If there's only one client connected to the session, they get detached
- If there's more than one client connected to the session (eg. when attached to the session from multiple terminal windows), none of them gets detached and we get a descriptive error on the CLI.
Okay, I understand the reasoning behind it, although I personally would prefer detaching all clients. Would you considered an additional flag, such as --all-clients, for the detach command?
From what I can gather, there is no straightforward way to determine if the 'Detach' action was initiated from the cli_client or the graphical client. Therefore, I created a new action called CliDetach (although I'm unsure about the name) that is exclusively used by the cli client. This would make it easier to check for a single connected client (in reality, there are two clients - the graphical one and the cli_client). Would this solution be acceptable, or would you prefer using a single action with some method of detecting if it was sent from the CLI or via a shortcut?
@imsnif Would it be unreasonable to conclude that the vast majority of the user base is using zellij as a tmux replacement? Shouldn't features be focused on that use case?
Zellij is not a tmux replacement. Zellij is not a screen replacement. Zellij is not a Byobu replacement. Zellij is not an i3 replacement. Zellij is not a browser replacement.
Zellij is Zellij. If you like it - use it. If you don't like it - don't use it.
Use it for its strengths, use it because it makes sense to you, use it because you want to be part of the journey, use it because it makes you feel good.
If you're trying to get it to behave like a different piece of software, I would heartily recommend you use said other piece of software. You would be happier in the end.
Wow, sorry if I offended you. I investigated zellij because I thought the "modes" paradigm was amazing. I wish you the best of luck.
Thank you. No offense taken.
Zellij is not a tmux replacement. Zellij is not a screen replacement. Zellij is not a Byobu replacement. Zellij is not an i3 replacement. Zellij is not a browser replacement.
Zellij is Zellij. If you like it - use it. If you don't like it - don't use it.
@imsnif I would agree with your sentiment, but... (there is always a 'but' - right?) - When using Zellij - for it's strengths, I can't use tmux/screen (maybe I can. but there is so much conflict and abstraction).
Zellij has it's strenghts, and as users of it (dare I say fans), we would like to make it even stronger.
Don't take offense by us mere-mortals who got to know Zellij after knowing the other tools - we all chose to ditch those tools because you created something superior in our minds eye. Take it as a complement.
I've been following the discussions and PRs for a long time now, and I know you don't take offense, but it does trigger you from time-to time, I am just offering a different vantage point.
As for the matter at hand, I would love a detach-all clients option if a detace-all-but me can't be achieved. BTW, a detach-all-but-me, can actually be: detach-all followed by reatach me. At least on a manual way, I'll have a way to kick off the tablet I forgot to exit from when I'm back at the computer.
In anyway, I'll keep on using Zellij, just because it makes so much else worht it.
Ventures into my psychology notwithstanding, this is actually a perfect example. Zellij can do this. You can detach all other users through the session-manager (Ctrl o + w and then Ctrl x). Since it's part of the session-manager, it's also part of the plugin API - meaning you can roll your own plugin and make it behave however you want.
While this is arguably currently more effort than doing so through the command line, it is incredibly more powerful if you take a step back and look what it means for integrations and other implications. I'm working on reducing the barrier of entry here and making this much easier to approach as both users and developers.
If one approaches this as a tmux user and asks "where is the CLI option that allows me to detach?", if one opens issues about it, implying to others who read the issues that this option is not possible in the application because they could not find it in the CLI, if one opens a PR for it, taking development time away from improving the accessibility to the APIs in favor of a review, one is not making the tool stronger - one is inadvertently trying to make the tool a clone of another tool and actually making it weaker.
In other words - I appreciate your thoughts and efforts. I am happy you like Zellij and want to improve it. But please trust in its direction and in its way of doing things rather than trying to make it behave like another tool. That way leads to imitation and stagnation, not to improvement.
if one opens a PR for it, taking development time away from improving the accessibility to the APIs in favor of a review, one is not making the tool stronger
I now understand your vantage point, and whole heartedly agree. Thanks for clarifying.