raphamorim
Restore previous Session on start
A feature I really like in the macOS default terminal is that it restores all tabs and their history when the application gets restarted (i.e. reboot or crash).
Something that is extremely annoying though is the fact that apple decided not to do this when the terminal is quit normally.
Having Rio restore all open tabs and their history on restart would be a great addition.
Hey @TitanNano thanks for the issue, sorry for the delay to reply.
When you mean restore session, we are talking about the opened tabs with the path they were using but no history right?
kinda of
Running
tab1 - path /Users/A/Desktop - last command `ls`
tab2 - path /Users/B/Desktop - last command `pwd`
tab3 - path /Users/A/Document - last command `vim index.md`
Suddenly closes
...
Reopen Rio
tab1 - path /Users/A/Desktop - restored session without command history
tab2 - path /Users/B/Desktop - restored session without command history
tab3 - path /Users/A/Document - restored session without command history
@raphamorim no worries, thanks for building this. Having the history of each tab restored would be nice to have, but what you proposed would be a great start.
🙏
Marking as wishlist to work later. If someone want to pick this up before I start to work on it, I plan to enable it through configuration (something like restore-session=true, reuse-previous-session-on-start=true) because then doesn't affect users that don't want this functionality.
@raphamorim I'm considering picking up this issue, as I really could use such a feature. I'm not really in the mood to take on a big piece of work right now, though, so I'm a bit torn.
To test the waters a bit and to align before doing anything, I was thinking I could lay out my thoughts here for now.
Looking at the current master, I think this could be done by giving the ContextManager the ability to a) dump / export all current contexts and b) initializing it from a list of existing contexts. When talking about dumping / restoring, I mean the rows stored inside the context.
What I'm not yet clear on is whether the ContextManager should also write the session backup to disk and load it, or if that should happen somewhere else. I'm also not sure if you have any preference for a data format to store such information.
I'd be happy to read your thoughts.
Hey @TitanNano thank you for reaching out! Yea, I think this might be a bit of work to implement but i would be happy to help if you decide to work on it! 🙏
Ideally the sessions should be stored as part of "server" (as tmux, wezterm does) or other source (file even). It all depends of what you want to restore, if is just restore the tabs with the path then I think not necessary would need to be a server and can it be done as you mentioned.
I am working right now on splits and I was planning to take this issue as my next "big feature" to rio, but would have to rewrite some stuff to work as a multiplexer. So if you had opened panels you could resume where you were at.
What I'm not yet clear on is whether the ContextManager should also write the session backup to disk and load it, or if that should happen somewhere else. I'm also not sure if you have any preference for a data format to store such information.
If you want to start suporting tabs/paths, then maybe we can just use restore-session=true as configuration, if is true then saves on ~/.config/rio/session.toml something like
sessions = [
{ window = [
# these are tabs
{ path = "~/Document/a/rio", extra_config_that_we_could_use... },
{ path = "~/Downloads", extra_config_that_we_could_use... },
]},
{ window = [
{ path = "~/Images", extra_config_that_we_could_use... },
]},
]
The thing is that we might need add some hooks on update_titles function for every time it runs and have an update then mark the file.
Once rio opens, if restore-session=true then load from session.toml and create the windows/tabs on demand.
if is just restore the tabs with the path
I was thinking to also restore the tab content, i.e., context.terminal.grid.raw.
I was thinking to also restore the tab content, i.e., context.terminal.grid.raw.
Feel free to add if you want to include in the first PR but could be better do it by steps. I think for restore the content might be better going towards to multiplexer (by making Context as an up and running server that can store states).