In reply to @gabrotst:matrix.org

Yes, I already knew that

To me it would seem obvious to also serialize it when the user quits Zellij, with it's current state.
It's intentionally not so?

In reply to @imsnif:matrix.org
I think I mostly didn't want anything delaying the Quit event. Users are very sensitive to even the smallest delay, and I don't want to have to maintain this delay as being Human imperceptible (eg. even if it's not Human imperceptible to begin with, some changes to the async-centric serialization-code might inadvertently make it perceptible)

Well Aram, first of all, congratulations for Zellij, it's really awesome on most aspects 🙂

However, for me it's extremely unexpected to lose the recent session activity when quitting manually.

Especially since there's no "manual save" command, that I'm aware of..?

In doing again what I lost I'll lose much more time than any delay that the serialization might introduce; and in many cases I just won't remember what is it that I did.
Hopefully I won't make a mess by launching again the commands that already completed, by the way..!

So, right now the only way to have the session saved (in the default configuration) is to wait 60 seconds?
Having to move away from the keyboard for 60 seconds, and remembering that you have to do that, doesn't seem more convenient than waiting a command to complete 😏

Besides, there's already a way to "quit" without any delay, that is detaching.

There doesn't even seem to be a point in a quitting command, if it doesn't orderly save things before terminating (or ask whether to do so).
Being quick in doing nothing, well it doesn't take much ;)
(ok, quit probably does do something, sorry 😄)

I'm very surprised if others haven't pointed this problem out before (I wasn't able to find GitHub issues addressing it).

Unless it's become common to just add "serialization_interval 1", as I did? (without noticing any increased resource utilization or delay)

By the way, if you really think it's important to handle the case of a slow serialization on quit, there could be a command to stop it («*Serialization in process, type ctrl q again to kill Zellij immediately *»).

In reply to @gabrotst:matrix.org

Well Aram, first of all, congratulations for Zellij, it's really awesome on most aspects 🙂

However, for me it's extremely unexpected to lose the recent session activity when quitting manually.

Especially since there's no "manual save" command, that I'm aware of..?

In doing again what I lost I'll lose much more time than any delay that the serialization might introduce; and in many cases I just won't remember what is it that I did.
Hopefully I won't make a mess by launching again the commands that already completed, by the way..!

So, right now the only way to have the session saved (in the default configuration) is to wait 60 seconds?
Having to move away from the keyboard for 60 seconds, and remembering that you have to do that, doesn't seem more convenient than waiting a command to complete 😏

Besides, there's already a way to "quit" without any delay, that is detaching.

There doesn't even seem to be a point in a quitting command, if it doesn't orderly save things before terminating (or ask whether to do so).
Being quick in doing nothing, well it doesn't take much ;) (ok, quit probably does do something, sorry 😄)

I'm very surprised if others haven't pointed this problem out before (I wasn't able to find GitHub issues addressing it).

Unless it's become common to just add "serialization_interval 1", as I did? (without noticing any increased resource utilization or delay)

By the way, if you really think it's important to handle the case of a slow serialization on quit, there could be a command to stop it ( "Serialization in process, type ctrl q again to kill Zellij immediately" ).

In reply to @imsnif:matrix.org
What's the problem with setting serialization_interval to 1?

Well for one, the setting is indeed not even documented, for now, if I'm not mistaken.

It might be me, but in a terminal multiplexer with session saving, I found it jarring that the last state didn't seem to get saved.

Until now I thought there was a bug.

In every software with the ability to save that I ever remember using, the quit command will either just save or ask to save, before actually quitting.
There will also usually be a manual saving command (that, granted, here seems overkill, a saving quit would be enough).

Being forced to rely on a timer for this, is really unsettling (to me).

If that timer were of one or very few seconds, though, it would indeed not be a huge deal.

But it's 60 seconds, by default..! Does anyone, in any workflow, benefit from that default?
And I don't even see this described in the documentation..!

I don't know if it's me, again, but I want to be sure that the stuff I want saved is saved; even having to wait few seconds, instead of being able to just type a command, would be uncomfortable.
Well, you seem concerned about saving users' time as well, no? ;)

Of course if it really would take changing the guts of the engine, it's different, but (from my perspective of a two-days user) it seems like it would just take adding a function call..?

I'd actually understand much more if there were no auto-saving; again, restoring an old command is dangerous even if you have to confirm it: you might not notice that the command is not the one you expected, and end up running it.

In reply to @gabrotst:matrix.org

Well for one, the setting is indeed not even documented, for now, if I'm not mistaken.

It might be me, but in a terminal multiplexer with session saving, I found it jarring that the last state didn't seem to get saved.

Until now I thought there was a bug.

In every software with the ability to save that I ever remember using, the quit command will either just save or ask to save, before actually quitting.
There will also usually be a manual saving command (that, granted, here seems overkill, a saving quit would be enough).

Being forced to rely on a timer for this, is really unsettling (to me).

If that timer were of one or very few seconds, though, it would indeed not be a huge deal.

But it's 60 seconds, by default..! Does anyone, in any workflow, benefit from that default?
And I don't even see this described in the documentation..!

I don't know if it's me, again, but I want to be sure that the stuff I want saved is saved; even having to wait few seconds, instead of being able to just type a command, would be uncomfortable.
Well, you seem concerned about saving users' time as well, no? ;)

Of course if it really would take changing the guts of the engine, it's different, but (from my perspective of a two-days user) it seems like it would just take adding a function call..?

I'd actually understand much more if there were no auto-saving; again, restoring an old command is dangerous even if you have to confirm it: you might not notice that the command is not the one you expected, and end up running it.

Again - all of these sound like mostly documentation issues. I understand that you'd like things to be different than they are - no harm in that. But you're going to have to take my word that the vast majority of users have different priorities than you in this case. This is honestly the first complaint I hear about this issue, and I will hear quite a lot of complaints if I add even a 100ms delay to the quit event (especially if it's not a consistent 100ms, but varies depending on what's running in the session).

The model of session-saving that I have is that of the browser. I'm a Firefox user - for me, the firefox session saving actually works considerably worse than Zellij. Most of the time it doesn't save my session (and gives a general error about it), it doesn't usually properly save the state of the websites I'm in very well, and it definitely doesn't categorize my sessions to different instances. It still is quite valuable in many ways and mostly doesn't get in my way.

Moreover: saving the state of a Zellij session is considerably more involved than saving the state of other programs such as editors or even web browsers. A lot of this state (eg. running commands and CWDs) is not stored in Zellij but rather in the OS. We have to query it in platform-dependent ways in order to get this information. These queries also have platform-dependent latencies, which means that if something is very fast for you, it will definitely not necessarily be very fast to someone running the same program on much cheaper hardware.

This is all a balancing act, and if you use the app you're going to have to trust me as its maintainer to make the right decisions. In the future, I might add a "Quit hook" (and other event hooks) to the plugin API to allow you to configure and change this behavior however you like.

In reply to @imsnif:matrix.org

Again - all of these sound like mostly documentation issues. I understand that you'd like things to be different than they are - no harm in that. But you're going to have to take my word that the vast majority of users have different priorities than you in this case. This is honestly the first complaint I hear about this issue, and I will hear quite a lot of complaints if I add even a 100ms delay to the quit event (especially if it's not a consistent 100ms, but varies depending on what's running in the session).

The model of session-saving that I have is that of the browser. I'm a Firefox user - for me, the firefox session saving actually works considerably worse than Zellij. Most of the time it doesn't save my session (and gives a general error about it), it doesn't usually properly save the state of the websites I'm in very well, and it definitely doesn't categorize my sessions to different instances. It still is quite valuable in many ways and mostly doesn't get in my way.

Moreover: saving the state of a Zellij session is considerably more involved than saving the state of other programs such as editors or even web browsers. A lot of this state (eg. running commands and CWDs) is not stored in Zellij but rather in the OS. We have to query it in platform-dependent ways in order to get this information. These queries also have platform-dependent latencies, which means that if something is very fast for you, it will definitely not necessarily be very fast to someone running the same program on much cheaper hardware.

This is all a balancing act, and if you use the app you're going to have to trust me as its maintainer to make the right decisions. In the future, I might add a "Quit hook" (and other event hooks) to the plugin API to allow you to configure and change this behavior however you like.

⁷Well yeah of course the app is yours, everything's up to you ;)

Ok, I didn't mean to have a long discussion here, I only wanted to understand if it was a bug or not (and I wasn't expecting to be nagging the maintainer 😏).

I'd say, yeah, that all these things should be documented very prominently, it's essential to know them if you're interested in the session resurrection feature.

I noticed that the feature is not very old though, that might be a factor in the number of complaints received ;)

I'm using Zellij on a super cheap old chinese smartphone, btw, I don't think anything can be fast for me 🤪 (I'd need it because the terminal app gets killed very easily)

Aaand I ditched Firefox's auto-save for reliable add-ons very quickly ;)

In reply to @imsnif:matrix.org
Come to think of it, you can already do this with plugins. You can use zj-quit as an example for hooking up to the quit event: https://github.com/cristiand391/zj-quit

In reply to @gabrotst:matrix.org
Hmm, there would still be the need for a "serialize" command/action though, to implement a save+quit or simply manual save plugin..?

In reply to @gabrotst:matrix.org

Well yeah of course the app is yours, everything's up to you ;)

Ok, I didn't mean to have a long discussion here, I only wanted to understand if it was a bug or not (and I wasn't expecting to be nagging the maintainer 😏).

I'd say, yeah, that all these things should be documented very prominently, it's essential to know them if you're interested in the session resurrection feature.

I noticed that the feature is not very old though, that might be a factor in the number of complaints received ;)

I'm using Zellij on a super cheap old chinese smartphone, btw, I don't think anything can be fast for me 🤪 (I'd need it because the terminal app gets killed very easily)

Aaand I ditched Firefox's auto-save for reliable add-ons very quickly ;)

And no worries. I can very much empathize, I know I personally also tend to understand things by arguing/debating them - and I don't think you were taking away from any other discussion here. Maybe others even found this interesting. A word of advice though (if I may): try not to assume you know more about an app's users and their needs than the person maintaining the app as reflected by the decisions they made. I know you didn't mean it this way - but this is what I do full-time and have been for a short while, I am very much aware of the needs and wants of my users.

Thanks for your input, in any case.

In reply to @imsnif:matrix.org
There is: https://zellij.dev/documentation/plugin-api-commands#dump_session_layout

In reply to @imsnif:matrix.org

And no worries. I can very much empathize, I know I personally also tend to understand things by arguing/debating them - and I don't think you were taking away from any other discussion here. Maybe others even found this interesting. A word of advice though (if I may): try not to assume you know more about an app's users and their needs than the person maintaining the app as reflected by the decisions they made. I know you didn't mean it this way - but this is what I do full-time and have been for a short while, I am very much aware of the needs and wants of my users.

Thanks for your input, in any case.

In reply to @gabrotst:matrix.org
Well doesn't that only serialize the layout?

Hi, guys. Is there any way to reorder tabs in current session? I'm missing this keybinding a lot

In reply to @fjeauntyd:matrix.org

Hi, guys. Is there any way to reorder tabs in current session? I'm missing this keybinding a lot

Alt-i: move tab left
Alt-o: move tab right

I believe these are relatively recent (they're bound to MoveTab "Left" and MoveTab "Right" in the default key bindings).

yeap, found these in docs too. thx

In reply to @imsnif:matrix.org
It's the same thing. This is the file used for serialization.

So it also serialize the viewport and the scrollback, ok.
That should probably be written in the documentation, and for clarity maybe the name should be changed to dump_session (with the older name still supported for compatibility).

But if I'm not mistaken, that command gives the plugin writer a string, and he has to figure out where to write it.

It seems like it would make sense to have a command that leaves all that to Zellij (and actually, ideally, an analogous action as well, which would let interested users obtain this feature with a simple key mapping).

In reply to @gabrotst:matrix.org

So it also serialize the viewport and the scrollback, ok.
That should probably be written in the documentation, and for clarity maybe the name should be changed to dump_session (with the older name still supported for compatibility).

But if I'm not mistaken, that command gives the plugin writer a string, and he has to figure out where to write it.

It seems like it would make sense to have a command that leaves all that to Zellij (and actually, ideally, an analogous action as well, which would let interested users obtain this feature with a simple key mapping).

In reply to @gabrotst:matrix.org

So it also serialize the viewport and the scrollback, ok.
That should probably be written in the documentation, and for clarity maybe the name should be changed to dump_session (with the older name still supported for compatibility).

But if I'm not mistaken, that command gives the plugin writer a string, and he has to figure out where to write it.

It seems like it would make sense to have a command that leaves all that to Zellij (and actually, ideally, an analogous action as well, which would let interested users obtain this feature with a simple key mapping).

In reply to @imsnif:matrix.org
Just a reminder that this tool is pre-1.0. Which means that as much as I agree with many of your points, there are _a ton_ of things to do, these being only a small part. Creating plugins is a way for users to fill-in basic functionality in the app that the maintainer(s) do not have the capacity for. But as mentioned in the plugin docs, this is a young ecosystem: one has the ability to influence things from the ground level by implementing lots of low-hanging fruit, but it also means there are some sharp edges. That's how these things go.

Well sure, I didn't mean to criticize or make any demands of course, just suggestions

I loved how quickly I was able to learn to use it, its interface and a lot of things, but yeah, there's things I'd like to have improved, for my use cases.

Unfortunately I don't know Rust yet, so I can't make code contributions.

But yeah, it's likely that the tool's user base is still quite small, that someone has held off because of previous or current deficiencies (session restoration is only 7 months old), so I would be open to suggestions that the current user base hadn't made yet ;)

Congratulations though, Zellij is seriously great work 🙂