Session resurrection

[imsnif]

This PR adds the ability to restore Zellij sessions after they have exited (gracefully or non-gracefully). We restore as much of the session as possible, allowing users to pick up where they left off between reboots or after crashes. Sessions can also be restored on different machines.

Special thanks to @AlixBernard who authored the algorithm for serializing layouts and to @alekspickle for integrating it with the codebase and providing guidance.

How does this work?

Session metadata is serialized once per second into the cache folder. We serialize sessions as a layout, so that they will also be Human readable and allow for manual adjustments as needed. These layouts can be loaded like any other layout inside any Zellij instance on startup (eg. zellij --layout my-dead-session.kdl).

We save these layouts to the cache folder and list them as EXITED in zellij ls (coming next PR: also in the session-manager). When the user attaches to an exited session, we'll resurrect the session for them (this is essentially the same as loading the cached layout with the --layout flag).

EXITED sessions can be deleted with the new zellij delete-session <session-name> or zellij delete-all-sessions commands.

What is restored / serialized

The session serialization includes all open tabs and panes. For each pane we record its CWD and if relevant, also its running command.

If we detect a pane is running a command, we'll serialize this command into a layout "command" pane, adding the start_suspended attribute to it. This will result in a prompt being provided to the user upon resurrection, asking them whether they want to run this command. This is so that dangerous commands such as rm or even cargo publish won't be immediately run on startup. This behavior can be bypassed when attaching (see below).

We can also optionally serialize and restore the contents of each pane, meaning the viewport and all or part of the scrollback. We do this with the new contents_file layout attribute added in this PR, serializing the contents to an ANSI file near the layout file in the cache folder. This behavior is currently opt-in (see below about configuring it).

The default session cache location for linux machines: ~/.cache/zellij/<ZELLIJ_VERSION>/session_info/<SESSION_NAME>/session-layout.kdl
The default session cache location for mac machines: ~/Library/Caches/org.Zellij-Contributors.Zellij/zellij/<ZELLIJ_VERSION>/session_info/<SESSION_NAME>/session-layout.kdl

How are sessions resurrected

Once a session is quit or has crashed, it will appear in zellij ls as EXITED

To resurrect it, we attach to it like any other session:
zellij attach <session_name>

When doing this, the commands in the session will be behind a prompt (Press <ENTER> to run) so as to avoid awkward situations with eg. rm -rf. This behavior can be bypassed with the new --force-run-commands flag.

To delete a resurrectable session forever, the delete-session command can be used, eg. zellij delete-session <EXITED_SESSION_NAME>. A running session can also be deleted with the --force flag. To delete all sessions, we can use the delete-all-sessions command, eg. zellij delete-all-sessions. When the latter is used with --force, this will delete all running and exited sessions on the machine forever (with a prompt).

How is this configured and what can be configured?

The session resurrection behavior can be enabled/disabled and configured in various ways.

To completely disable this feature, we can set session serialization false in the zellij configuration. This can also be done on a per-session basis with the --session-serialization false CLI option.

When session serialization is enabled, we can opt-in to also serialize the pane viewport (the contents of each pane that appear on screen without scrolling up). This can be done similarly with the pane_viewport_serialization true attribute in the zellij configuration. This defaults to false for privacy reasons.

When pane viewport serialization is enabled, we could also serialize and restore the pane scrollback. This can be done with the scrollback_lines_to_serialize <line_count> configuration attribute. If set to 0, we'll serialize the entire scrollback. Note that this can end up costly in system resources (both in regards to storage space and serialization performance).

New Additions

To facilitate this feature, some new smaller features and additions were made. Some of them a long time coming on their own. These are:

new_tab_template Layout property

This layout attribute can be used similarly to other layout templates to indicate how a new tab should be created in a session created with this layout.

hide_floating_panes Layout property

This layout attribute can be used inside a tab node to indicate that when starting up this tab, any floating panes defined in this layout should start hidden.

contents_file Layout property

This layout attribute can be used inside a pane node to point to an external ANSI file (relative to this layout path) that will contain the contents of this pane upon startup. We use this for the viewport serialization described above, but it can theoretically be used for banners, warnings or whatever one's imagination can come up with.

dump-layout CLI command

In addition to having the session periodically serialized to disk, we will now also be able to do this with a CLI command to STDOUT. zellij action dump-layout will print the layout of the active session to STDOUT. Combined with the --session flag (eg. zellij --session my-session-name action dump-layout), it could also do this for other running sessions on the machine.

[alekspickle]

you can just do this, I believe behavior is the same

Suggested change

	let _ = self.set_pane_frames();
	_ = self.set_pane_frames();

[imsnif]

Thanks, I appreciate the comment but I see this as cosmetic