Proposal for auto-save about tmux-resurrect HOT 23 CLOSED

@************ I think it's called continuum now: https://github.com/tmux-plugins/tmux-continuum

from tmux-resurrect.

This would be easy to implement, but how would you handle the following scenario with auto save turned on:

1. you work in tmux and auto-save happens. all is good.
2. you restart the computer
3. you open a new tmux session
4. before you restore previously saved session, auto save kicks in again and effectively rewrites your last valid save point 💥
5. you try to restore tmux env, but nothing happens because automatic saved happened seconds ago

So, I'm also +1 for this feature after we figure how to properly handle or avoid step 4. above.

from tmux-resurrect.

+1

from tmux-resurrect.

Would it be possible for tmux-resurrect to have auto-load feature as well?

1. You enable auto-saving in config
2. tmux auto-saves your session
3. You restart your computer
4. tmux stops auto-saving, checks if it's enabled in config, checks if there is auto-save file
5. Loads latest auto-saved file
6. Continue as normal

from tmux-resurrect.

@dkns Great idea!

from tmux-resurrect.

@bruno- just spitballing, but perhaps on init, but could you check if uptime is more recent the the most recent save, then ask if you want to overwrite or save load?

from tmux-resurrect.

On OSX windows are restored/resumed (if the feature is supported by the app and enabled) upon reboot. There is no opportunity to open a new window in an app, until the previous version has been restored. Short of doing this, you could just throw up a dialog asking the user if they'd prefer to restore previous sessions or continue without a restore (in which case the previous auto-saved data would be overwritten).

from tmux-resurrect.

+1 (including the idea by @dkns)

from tmux-resurrect.

+1, happy to help with implementation if it can be broken into sub tasks.

EDIT: happy to do full implementation if no one is working on it already

from tmux-resurrect.

Auto save combined with bash history save (#48) would be truly awesome.

from tmux-resurrect.

I've been researching and thinking about this. We have history save/restore available already and I'm working on a patch for pane-buffers save/restore, which is the next logical step (I think):

Save/Restore Buffers Feature #62

I suppose auto-save/restore could be implemented by triggering a script or command via the status line, in which case the status line update interval (status-interval) would regulate how frequently auto-save occurs. I'm not sure how else this could be implemented without using an external cron job or other timing mechanism.

What I'm interested in is the auto restore functionality that the native OSX terminal.app features, where the terminal does not lose its history or history-buffer upon reboot. The effect could be achieve pretty closely by using an auto-save interval except for one thing: saving is (currently) obtrusive.

Another angle I'm looking at is support in tmux itself for 1) hooks, 2) hooks triggered by trapping signals. There is work already to implement #1, but probably not #2. What I'm getting at, is that it would be pretty useful (IMHO) to trigger a save when tmux is sent a SIGHUP, EXIT, SIGTERM, etc. That would handle the reboot scenario. It would not handle a crashing scenario.

As for the auto restore part... Currently tmux will not restore existing windows. This does and doesn't make sense. It makes sense in that the goal is not to overwrite data in an existing pane; it doesn't make sense in that it makes it impossible to restore the very first pane. Ways around this:

• prompt the user
• renumber windows and restore panes (i.e. window 1 is a new windows, restored panes 1-n become 2-n)
• check the history-buffer length and if it's empty (minus the prompt), go ahead and restore everything because the user has not started doing anything yet.

The one gotcha with automatic save on exit is that if the user has closed any panes (let's say by accident) their history will be deleted on save (because the closed panes don't exist anymore). One solution would be to store each save in its own .tmux/resurrect/restore-TIMESTAMP directory. And add an option to only save X number of restores so we can start cleaning up some of this stuff. Whenever we start tmux we can prune the restore directories.

from tmux-resurrect.

@markeissler There is an explanation and solution for the "not restoring first window" problem, it's because restore shouldn't clobber an already-open window. Just save a named session, that way there is no conflict with restoring to the session named 0.

This isnt to say that I don't like your bullet list, checking the history length and making an assumption that the fresh window can be discarded will probably work very well. I will usually spam ls at least 3 times before putting important work into a given terminal so if something has only a shell prompt, it can be nuked on sight.

The only other comment I would make is that I consider auto saving of the session to be 90% of the reason to have saving of sessions at all. I don't want to baby sit this, I want it to just remember, like Sublime does and like tpope/vim-obsession does. Sometimes I have ~15 files open in vim that I already know ahead of time that I want to be able to auto-reopen, and I started to actually run a script that involves :mksession. But after a week of that, I discovered vim-obsession and it delivers on the warm-and-fuzzy feeling.

The other 90% is that 90% of the time I never actually close tmux, tmux generally dies when my computer dies. The only such times are when I have made such significant modifications to my tmux configuration that I have to kill the server. The last time I did this was when I upgraded my tmux from 1.9a out of homebrew to when I compiled commit 3e8efcc. I had to kill tmux then...

My Macbook usually crashes before I reach 30 days of uptime. Last time it was a GPU driver hiccup, and next time God only knows. So any auto save really must handle a crash scenario so it would be best to be triggered by events, like vim-obsession does.

At any rate, saving at the moment of closing tmux is still useful. I have been known to close tmux a few times. On Linux.

from tmux-resurrect.

@unphased Unless I'm missing something (!) when you trigger restore you are restoring panes for the session that you are already in, there's no way to restore a saved session with one name to a session with another. Again, maybe I'm missing something. :)

NOTE: When I'm discussing the ability to perform backup/restore I'm specifically including the history and history-buffer restore features, which specifically will only restore to a session by the same name.

Perhaps our workflow is different? After my Mac crashes, I startup tmux with a session name that is always the same. And then I restore the session data (from the last backup). So I will always have an already-open first window when I restore. (Wouldn't this be what happens to everyone?) My desire is to have my tmux session restored exactly as it was (same session name, same number of windows, panes, and each with their shell history and history-buffer restored).

The salient point, in your response, is that there's a need to auto-save backup points simply because we can't anticipate a crash. That's a valid point. So, the solution would probably be a combination of auto-save and save on exit (term, HUP, etc.). That way you can be sure that you have most of the data from before a crash, and all of the data from after a normal exit.

Again, unless I'm missing something, tmux does not currently provide an API for events that we can leverage. There is a feature branch that hopes to add hooks to tmux, but there's no ETA for a merge to master right now (AFAIK) and it looks like the hooks won't help us with auto-save in any case, nor will they include signals support.

from tmux-resurrect.

@markeissler I didn't test it extensively but I did test this. I made a session with a few panes and i named the session zz, by using prefix+$. I used save. It worked. Then i :kill-servered tmux and started it up again and i'm now session 0, the default. Then i restored, and it brought me to session zz because that's what I saved. I could use whatever method (menu, bind, command) to return to session 0 which is as I had left it. Now if I had originally saved a default-named 0 session, upon restoring when I'm on 0, it refuses to clobber.

And as for the rest, yeah, I mean none of this is honestly all that important. I've gotten along just fine losing every damn thing when I crash, and I got along just fine without tmux for a while before that. I will have no real issues remembering to hit prefix+ctrl+s when I have my panes set up to my satisfaction. So yeah auto save would be nice but what we get already is pretty good too. We have to live with the limitations with everything anyway.

from tmux-resurrect.

Hey guys, a lot has been said... I didn't know you have issues with crashes so often. That certainly makes an autosave feature request more valid.

If someone wants to take action on this, I think a separate tmux-resurrect-autosave plugin could be made pretty easily. Here's the general idea:

• the key thing where you can "hook" is tmux's status bar. status-right is refreshed every status-interval seconds (15 by default). If for example string like this #(autosave_script.sh) is put in status-right, then that will execute autosave_script.sh every 15 seconds.
• you probably don't want to save every 15 seconds, so you build some simple mechanism to store the time of the last save and check if enough time passed till then. If enough time passed (a day?), then run save (ta-da: tmux based cronjob).

As mentioned above, it's probably best this be a separate plugin (not included in tmux-resurrect). That way things are more maintainable and users don't have to fiddle with options. They just install resurrect-autosave and things just work.

If someone wants to take this I'd be glad to help with support and answering questions. When it's done, we can link the repo from this project's readme.

from tmux-resurrect.

@bruno The OSX crashes seem to be recent for me and possibly related to vmware + OSX 10.10.

I disagree that this should be a separate plugin. The feature is dependent upon tmux-resurrect after all. It would just be one more option: to enable or disable auto-save. If enable is set to 0 (minutes), then auto-save is off, anything other positive value would indicate the feature is turned on. Whether or not auto-save should be turned on by default is up for discussion--right now I'd say it probably should be on by default.

I can take a look at this once I'm satisfied with the history-buffer feature (Save/Restore Buffers Feature #62) I've been working on.

from tmux-resurrect.

I disagree that this should be a separate plugin. The feature is dependent upon tmux-resurrect after all.

@markeissler I kinda agree with this. Also your "interface"/option description for this feature is good.

I proposed making this a separate plugin just to make the maintenance easier and offload it from tmux-resurrect.
I feel I'm lagging on a lot open pull requests and issues (yours included) and taking more code into this plugin certainly wouldn't help offloading this... No other reason than this, really.

from tmux-resurrect.

Hmmm. No worries @bruno! I've been lagging on making a couple of changes to my history-buffer patch. In the meantime, I've just been "using" the patch to see what needs improvement.

from tmux-resurrect.

Update: I've started working on this issue. It will combine my previous efforts on:

Save/Restore Buffers Feature #62

The feature aims to be as transparent to the user as possible.

from tmux-resurrect.

Hi guys, there's now a separate plugin that does auto saving tmux-resurrect-auto.
I'd appreciate if someone can try it out and report if everything is okay.

Other than that I think this issue can be closed. If tmux-resurrect-auto has any issues let's open them in a that project.

from tmux-resurrect.

Sweetness. You're the best, @bruno-

from tmux-resurrect.

Hi guys,
tmux-resurrect-auto just got a new feature: automatic restoring when tmux server is started.

Thank you for the kind words @unphased.

from tmux-resurrect.

tmux-ressurect-auto link is dead.

from tmux-resurrect.