GNOME Bugzilla – Bug 575242
New composer window not autosaved until modification
Last modified: 2015-06-04 19:43:15 UTC
Please describe the problem: When opening a new composer window, e.g. with ctrl(-shift)-R, it is not autosaved until something in it is modified. As a result, the composer window will not be restored after a restart of Evolution, e.g. after a crash. I will attach a patch which fixes this. The patch still leaves a window of up to one minute until the next autosave run; I think ideally the new composer should be autosaved once immediately, but I'll leave that to the Evolution developers. Steps to reproduce: 1. Open a new composer window 2. Don't make any modifications in it Actual results: No ~/.evolution/.evolution-composer.autosave-* file appears for it after any amount of time. Expected results: Does this happen every time? Yes Other information:
Created attachment 130582 [details] [review] Possible fix This just removes the composer dirty check from e_composer_autosave_snapshot().
It might be nice to distinguish whether new composer windows are seeded with initial text (via reply, forward, or "Edit as New Message") before auto-saving immediately, so we're not restoring blank composer windows.
Indeed it might, though OTOH even a blank composer window could serve as a reminder that one meant to write some mail to someone. :)
So, is there any chance for something like this to go into 2.26.x? Anything I need to do for that?
I still don't want blank windows to be auto-saved. Looks like new composer windows that are seeded with initial text are initially marked dirty by EMsgComposer, but then we revert that in em-composer-utils.c through composer_set_no_change(). Might try adding a boolean parameter that controls whether we call e_composer_autosave_set_saved(), and pass FALSE from the appropriate places (or just kill the function and inline the logic). I think that should get you the right behavior.
Created attachment 133722 [details] [review] Only autosave populated composers This should do what you suggested. I verified it doesn't autosave an unmodified empty composer window but does autosave an unmodified reply.
I'd suggest renaming the function argument from "call_editor" to something like "set_changed", but otherwise it looks good. Please commit to master only, or I can if you don't have a GNOME account.
(In reply to comment #7) > I'd suggest renaming the function argument from "call_editor" to something like > "set_changed", but otherwise it looks good. Please commit to master only, or I > can if you don't have a GNOME account. I don't, so I'd appreciate if you could push it with the change above, thanks. Do you think this could be appropriate for the 2.26 branch as well?
No problem, I'll take care of it. Looks safe enough for the 2.26 branch.
Patch committed to master and gnome-2-26 branches: http://git.gnome.org/cgit/evolution/commit/?id=565403aa1fcacc00c80618287a0cf3e71fb888d1 http://git.gnome.org/cgit/evolution/commit/?h=gnome-2-26&id=3f451ec5d4ed7b524d6dc106679d32a8dad9612a
This bug is back in 2.29.92.1, at least when replying: there's no autosave file until I change something in the composer.
AFAICT this was reintroduced by commit abc690c6ff4215f77e41f3cc779435746be7ca88, the fix for bug 599794. Maybe the dirty state just needs to be tracked completely separately for drafts and autosaves, as was done in my original patches for bug 220672 (the latest patches proposed there don't fix this problem).
The composer autosave module code says this: /* User may have reverted or explicitly saved * the changes since the timeout was scheduled. */ and below it checks whether to save or not based on the stored 'changed' flag from the last try on the composer. I do not think it's correct, because if the user explicitly saves the message then the autosaved will contain an old version. I removed this private flag from the autosave code, and it also causes autosave of empty mail and replies and such. Created commit bd0ace7 in evo master (3.17.3+) Created commit 5a6f460 in evo gnome-3-16 (3.16.3+)