-
Notifications
You must be signed in to change notification settings - Fork 418
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal for auto-save #35
Comments
+1 |
This would be easy to implement, but how would you handle the following scenario with auto save turned on:
So, I'm also +1 for this feature after we figure how to properly handle or avoid step 4. above. |
Would it be possible for tmux-resurrect to have auto-load feature as well?
|
@dkns Great idea! |
@bruno- just spitballing, but perhaps on init, but could you check if |
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). |
+1 (including the idea by @dkns) |
+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 |
Auto save combined with bash history save (#48) would be truly awesome. |
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:
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. |
@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 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 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 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 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 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. |
@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. |
@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 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 |
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
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 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. |
@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. |
@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 |
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. |
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. |
Hi guys, there's now a separate plugin that does auto saving tmux-resurrect-auto. Other than that I think this issue can be closed. If |
Sweetness. You're the best, @bruno- |
Hi guys, Thank you for the kind words @unphased. |
tmux-ressurect-auto link is dead. |
@cirosantilli I think it's called continuum now: https://github.com/tmux-plugins/tmux-continuum |
Would it be possible to set up auto save for tmux-resurrect.
Just two extra configuration settings: enable or disable autosave and autosave interval.
The text was updated successfully, but these errors were encountered: