See bug https://bugs.documentfoundation.org/show_bug.cgi?id=122530 I don't mean a separate period per document. I mean, please make the start time used for checking whether auto-save is needed or not, a thing that is measured using properties of that document only. The reason for this is that auto-save can take a long time, disrupting work flow. An alternative would be if the auto-save did not block normal editing of the document so you could continue working, but I imagine that would be far harder to achieve and could introduce errors into the saved file. Perhaps see also the request to document the existing behaviour - 144511
If auto save timing would be an option it should not be available in the UI but expert settings only. And in fact it is at Common/Save/Document/AutoSaveTimeIntervall (but unclear in respect to the same variable at Recovery/*). The solution is clearly to not block editing while saving. Tricky thing as running the operation in the background makes the content inconsistent. IIRC we had this in the ESC and somehow it should be fixed. But IMO not per option.
(In reply to Heiko Tietze from comment #1) > If auto save timing would be an option I'm afraid it's some confusion here. The request is to make it an per-doc *action*, not per-doc *option*. (Not blocking during save is orthogonal; while it could help, *possibly* this one would still be relevant.)
There is likely no ODF setting for autosave on/off.
(In reply to Heiko Tietze from comment #3) > There is likely no ODF setting for autosave on/off. Definitely. And no need for that. Again: the request is not to *disable* or make it configurable; the request is to count the save timeout (which has same value for every document!) separately for each document, starting from its last dirty time. So that document 1 gets auto-saved when e.g. 10 minutes elapsed since *its* edit took place that made it modified; document 2 would auto-save when the same 10 minutes elapsed since *its* dirty time, and not when document 1's timeout happened, etc.
I was presuming that timeout is counted for individual documents. If not, sure, do it! No need for UX then...
Thanks for your comments Mike: exactly what I was trying to say.
(In reply to Heiko Tietze from comment #5) > I was presuming that timeout is counted for individual documents. If not, > sure, do it! No need for UX then... => NEW
Don't hold your breath. It would take a major re-write to implement.
If you say so. I don't mean a per document *preference* for the auto-save period, just to be clear. Just that if the auto save period is say 30 mins, it only kicks in and saves documents that have been unsaved for 30 mins or more.
(In reply to Justin L from comment #8) Why? I suppose that the timer function could only save those documents that are already more than 10 minutes dirty; and find the document, which dirty time is largest but less than 10 minutes, and set the new timeout to trigger after the due time to save that document, and so on.
Because it can lock up Writer for 40 seconds or more, and make you lose your flow, if you dare to have multiple documents open and one of them is dirty. It happened to me over and over and over again while I was writing my novels. For a while I tried turning it off. I think in the end I changed it so it only auto-saved every hour. The implementation of this feature was so painfully disruptive that it trained me into manually saving frequently. So, that's the reason.
(In reply to Luke Kendall from comment #11) Which question are you answering? ;)
(In reply to Mike Kaganski from comment #12) > (In reply to Luke Kendall from comment #11) > > Which question are you answering? ;) Oops, sorry, I was indeed mistaken. I misread your question thinking it was directed to me, and failed to notice your question was directed to Justin L's comment.
I don't see how separating them would be of any help: -once they have been autosaved, they won't have impact again unless becoming dirty - meaning the user is frequently switching between/editing multiple docs. -if the save of a non-active document affects the working document (likely true) - then having staggered saves would actually be even more disruptive -while if the save of a non-active document doesn't affect the working document - then it is somewhat irrelevant when it auto-saves Staggered saves would just mean more frequent (but shorter) interruptions during idle times. That doesn't sound beneficial to me.
(In reply to Justin L from comment #14) > -once they have been autosaved, they won't have impact again unless becoming > dirty Wrong! That is only (theoretically) true if UserAutoSave is actually saving the document itself. Otherwise the modify flag remains unchanged. AFAIK, there is currently no way that AutoSave can tell if the document has changed since last AutoSave, so it will run every time (until the user manually saves the file).
(In reply to Justin L from comment #15) > (In reply to Justin L from comment #14) > > -once they have been autosaved, they won't have impact again unless becoming > > dirty > Wrong! That is only (theoretically) true if UserAutoSave is actually saving > the document itself. Otherwise the modify flag remains unchanged. AFAIK, > there is currently no way that AutoSave can tell if the document has changed > since last AutoSave, so it will run every time (until the user manually > saves the file). The modified flag of the *document* remains unchanged; but the modified flag of IMPL_SfxBaseModel_DataContainer changes. So your comment 14 is correct. (In reply to Justin L from comment #14) > I don't see how separating them would be of any help: > -once they have been autosaved, they won't have impact again unless becoming > dirty - meaning the user is frequently switching between/editing multiple > docs. > -if the save of a non-active document affects the working document (likely > true) > - then having staggered saves would actually be even more disruptive > -while if the save of a non-active document doesn't affect the working > document > - then it is somewhat irrelevant when it auto-saves > > Staggered saves would just mean more frequent (but shorter) interruptions > during idle times. That doesn't sound beneficial to me. Generally I agree with all these facts. I just don't know how shorter (but same-length in total) would affect user psychologically. The just-changed document will not autosave immediately, just because monotonically ticking timer happened to fire now; but it will autosave in 15 minutes; so if user expects less saves, this expectation is wrong. However, I prepare an experiment implementing this. I suppose it won't really help users, but OTOH it won't hurt - if this change is merged, and Luke would download and use a daily with it for some time, and report back, then we may see if the idea worth it, or revert.
I'm happy to try a special version to try this out. I understand and agree with both of Justin L's comments (#14 & #15). I think this point is especially interesting: -if the save of a non-active document affects the working document (likely true) - then having staggered saves would actually be even more disruptive I have direct experience of editing multiple related long documents together, and can state that one unsaved and modified document will trigger an autosave for all such docs. For me personally, the autosave is so disruptive, on a long document with lots of comments for example, because it can take so long, is that when you get caught because you forget to manually save doc A after a change and went back to doc B, that when you're forced to stop and wait by an autosave, it reminds you to manually save the docs you forgot to, and then continue work on whichever doc is your main focus of attention. So I'm hopeful that in practice the change will reduce the number of interruptions despite the truth of Justin's point in comment 14. Regarding comment 15, that's completely correct behaviour - although it seems to me, if Writer saw that the modification time of the doc was older than the last autosave it had done for that doc, that another autosave is redundant and just wasteful of time and energy.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79113484cacb630f93f87c483b6c5d97c47b8728 [API CHANGE] tdf#144512: keep autosave interval separately for each document It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Luke Kendall from comment #17) Luke, as mentioned in the commit notification, the builds containing this change are expected tomorrow, or in case of some failure, the next day after. Please test if this fulfils your expectations. Thanks!
I'll try. I'm assuming it's a 7.5 series build? So I'm looking in https://dev-builds.libreoffice.org/daily/libreoffice-7-5/Linux-rpm_deb-x86_64@tb87-TDF/ which includes a directory named 2023-07-18_16.37.24/ but I couldn't see anything labelled 24.2.0 It's a little difficult for me at the moment as I may have to leave home for a few days due to family health problems, but I'll see what I can do.
(In reply to Luke Kendall from comment #20) > I'll try. I'm assuming it's a 7.5 series build? No :) it is a master build. https://dev-builds.libreoffice.org/daily/master/current.html But it seems, that there's no builds for Linux from today.
One nice result from this change: -start a new document -wait 9 minutes -start typing -autosave now waits for 10 minutes, instead of triggering 1 minute later.
Sorry for the stupid question, but where do I find 24.2.0? If I look under https://dev-builds.libreoffice.org/daily/libreoffice-7-5/Linux-rpm_deb-x86_64@tb87-TDF/ I see Parent directory/ - - 2023-07-18_16.37.24/ - 2023-Jul-18 14:37 2023-07-21_23.21.35/ - 2023-Jul-21 21:21 2023-07-25_03.30.30/ - 2023-Jul-25 01:30 2023-07-26_03.15.57/ Does 24.2.0 mean 2023-07-18_16.37.24/ ?
(In reply to Luke Kendall from comment #23) > Sorry for the stupid question, but where do I find 24.2.0? https://dev-builds.libreoffice.org/daily/master/current.html
I think it's working as expected. I tried some fancier tests on a bigger doc but couldn't easily tell due to the many thousands of lines of these two repeated lines of output: warn:linguistic:448474:448474:linguistic/source/lngprophelp.cxx:632: unknown property 'HyphNoLastWord' warn:linguistic:448474:448474:linguistic/source/lngprophelp.cxx:632: unknown property 'HyphZone' But I think it's working fine.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fe55282c02a3306ac1c7971a5c2c85c52f54d205 tdf#144512 autorecovery: don't delay autosave on shutdown It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
OPs request has been implemented. So lets mark this as fixed. (Whether users like this or not remains to be seen. Getting saves to be async should alleviate any complaints [bug 48416], but generally users don't jump between documents that much, and it only saves once for background docs.)
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c3cf88f73e29a79f890782b31d1ecc6ed1c376ea tdf#144512 autorecovery: only wait once for user idle It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90b23d0b4528a12ababa3c2897ab3f1a3719b2f1 tdf#144512 autorecovery: always wait for user idle with timed save It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c3cb2f956d760ba6ddd9a882e952b2bd7c1af145 partial Revert "tdf#144512 autorecovery: always wait for user idle... It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Justin L from comment #22) > One nice result from this change: > -start a new document > -wait 9 minutes > -start typing > -autosave now waits for 10 minutes, instead of triggering 1 minute later. Justin, I have a question. I set the time to 1 minute for backup. I'm opening a single document and working without a break 3 hours. When the backup will be triggered when continuous typing, without any idle time?
(In reply to BogdanB from comment #31) > I'm opening a single document and working without a break 3 hours. When will > the backup be triggered when continuous typing, without any idle time? It will wait for an idle period (and always has). If you work for 3 hours without a 10 second break, you will not get a timed backup. (Basically, once the timer is set for IDLE, there is no "second timer" running to ensure that an idle occurs in a "reasonable" about of time.)
Here is the current help page for the AutoRecovery options: https://help.libreoffice.org/24.2/en-US/text/shared/optionen/01010200.html?&DbPAR=WRITER (aside from the incorrect dialog image), are additional changes, improvements needed in this page, in light of this change (or other recent changes to AutoRecovery)?
(In reply to sdc.blanco from comment #33) > Are additional changes, improvements needed in this page. Save AutoRecovery information every: needed to restore all MODIFIED documents #([requested] change in behavior) Automatically save the document too: saves all MODIFIED documents #(this was always true) If you want to add too much information, you could add Minutes: Specifies the time interval in minutes for the automatic recovery option. (Save occurs during the next user idle period.)
(In reply to Justin L from comment #34) > Minutes: > Specifies the time interval in minutes for the automatic recovery option. > (Save occurs during the next user idle period.) The Tools -> Options -> Load/Save/ -> General tab is not really clear about the '10 minute' interval. I would read it: every 10 minutes. Not 10 minutes starting from idle. And well I personally find 10 minutes starting from idle pretty long time.. I might be multi-tasking in between, and back editing after 8 minutes. The AutoRecovery wouldn't store anything.. In my perception a 2 minutes time frame would be more reasonable. Or I'm overlooking the obvious? Note: what will happen in case of an EmergencySave. Which document will the document recovery dialog try to restore: the EmergencySave or the AutoRecovery information. Background: the EmergencySave isn't always successful. It might be initiated, but (a) freeze (b) save, but hang on recovery. There is quite a change that the stored AutoRecovery variant would be intact. However if you're unable to access the AutoRecovery information..
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/2aa198ab57081bed9c012ea49c25fcd9d05dbfcb (related) #tdf144512 change in AutoRecovery behavior
(In reply to Telesto from comment #35) > (In reply to Justin L from comment #34) > > Minutes: > > Specifies the time interval in minutes for the automatic recovery option. > > (Save occurs during the next user idle period.) > > The Tools -> Options -> Load/Save/ -> General tab is not really clear about > the '10 minute' interval. I would read it: every 10 minutes. Not 10 minutes > starting from idle. I see there's a clear and good note about this now in the help page link provided in an earlier comment, that it's 10 minutes since last... modification! I misread that at first as "since last save"! "A timer starts for a document when it is first modified. AutoRecovery information is saved after the specified time (while LibreOfficeDev is idle). The timer then restarts with the next modification in the document" > And well I personally find 10 minutes starting from idle pretty long time.. > I might be multi-tasking in between, and back editing after 8 minutes. The > AutoRecovery wouldn't store anything.. In my perception a 2 minutes time > frame would be more reasonable. Or I'm overlooking the obvious? > [snip] I agree, if we're talking about 10 minutes from a modification to the document. I hope this is an error in the documentation, otherwise this change will be terrible, resulting in no saves if you're continuously modifying a document. So you could work 12 hours in some frantic mode, experience a crash, and lose the whole thing if you were foolish enough never to save manually! It never occurred to me that the time interval might be measured from last modification rather than last save! So, there is either a bug in the implementation, or a bug in the feature. I'm using 7.5.3.2: I'll try to see whether it's the Help text or the code that's wrong. (My guess and hope is that it's the documentation!) Another problem with the Help is this description: "Save AutoRecovery information every Specifies that LibreOfficeDev saves the information needed to restore all modified documents in case of a crash." This begs the question: does the AutoRecovery information differ from a normal save? If I'd made changes to a document and Writer crashes, with the AR restore the changes I made to the document? If so, why do you need an option to save the document too? Anyway, I can see those are comments or bugs to report on the documentation (assuming the Save period is measured from last save, not from last change).
(In reply to Luke Kendall from comment #37) > I see there's a clear and good note about this now in the help page link > provided in an earlier comment, that it's 10 minutes since last... > modification! I misread that at first as "since last save"! > > "A timer starts for a document when it is first modified. AutoRecovery > information is saved after the specified time (while LibreOfficeDev is > idle). The timer then restarts with the next modification in the document" > > > And well I personally find 10 minutes starting from idle pretty long time.. > > I might be multi-tasking in between, and back editing after 8 minutes. The > > AutoRecovery wouldn't store anything.. In my perception a 2 minutes time > > frame would be more reasonable. Or I'm overlooking the obvious? > > [snip] > > I agree, if we're talking about 10 minutes from a modification to the > document. > > I hope this is an error in the documentation, otherwise this change will be > terrible, resulting in no saves if you're continuously modifying a document. > So you could work 12 hours in some frantic mode, experience a crash, and > lose the whole thing if you were foolish enough never to save manually! I am sorry, I do not see how could the quoted phrase, telling explicitly that the timer starts when the document is *first* modified; saves the document when it's over (and there is an idle moment - which is basically the same moment, given the GHz clocks in current CPUs, one simply can't physically saturate the system for long time, no matter how much you try); and that the timer starts again *AFTER THAT* on the *next* modification (and there is not a single word, that it restarts on following modifications until its time is over and saved).
So - again: 10 minutes in *neither* from last save, *nor* from last modification; it is from the *moment when the document became modified*. Every autosave marks it "unmodified" (internally; it is indeed still unsaved for the purpose of normal save; but it is a different story); a normal save marks it unmodified universally; the next change after the autosave or normal save marks it modified, and starts the autosave timer; and after that, the following modifications do not alter the "modified" status, and do not change the timer timeout moment, until a save occurs (automatic on timer timeout, or manual). If this *does not work this way*, it would be a bug. If the documentation fails to make it clear, improved wording would be welcome.
(In reply to Mike Kaganski from comment #39) > So - again: 10 minutes in *neither* from last save, *nor* from last > modification; it is from the *moment when the document became modified*. > Every autosave marks it "unmodified" (internally; it is indeed still unsaved > for the purpose of normal save; but it is a different story); a normal save > marks it unmodified universally; the next change after the autosave or > normal save marks it modified, and starts the autosave timer; and after > that, the following modifications do not alter the "modified" status, and do > not change the timer timeout moment, until a save occurs (automatic on timer > timeout, or manual). > > If this *does not work this way*, it would be a bug. If the documentation > fails to make it clear, improved wording would be welcome. I see! Good! The problem is this sentence: "The timer then restarts with the next modification in the document." The "next modification" to me is ambiguous. The correct interpretation is that "next" refers to "latest autosave", but I interpreted it to mean "next modification made to the document" - which would be foolish. Personally I'd phrase it as: "The timer then restarts with the first modification after save."
(Hitting TAB appears to submit a comment.) "The timer is restarted at the first modification after each subsequent save." I think would be unambiguous and cover all that you explained, Mike. (Thanks!)
(In reply to Commit Notification from comment #36) Seth, please consider the above; and also - from my PoV, the mention of the "(while %PRODUCTNAME is idle)" is unneeded in Help, because it's just an implementation detail. The save interval must - for all practical purposes - define when the save happens. We have an internal "delay it for a few milliseconds if busy, to not interfere with current operation processing" - but that should not affect the visible behavior. If it would affect it (say, in certain situations some processing would prevent the autosave for an hour), it would be a bug, requiring either fixing that long processing, or our delay logic. Documenting it makes such a problem *look* legit, when it will be not.
(In reply to Mike Kaganski from comment #42) > Seth, please consider the above; and also - from my PoV, the mention of the > "(while %PRODUCTNAME is idle)" is unneeded in Help Thanks Mike. I agree with your POV. Fwiw, Justin Luth and I discussed this issue for a long time, as you probably saw in Gerrit (and then further in private mail). The sticking point was: #define MIN_TIME_FOR_USER_IDLE 10000 // 10s user idle in framework/source/services/autorecovery.cxx, which made us believe that a longer idle period was required (see comment 32). If that was a misunderstanding, and the idle is on the order of ms as you explained here, then I agree that the parenthetical remark should be dropped. Can you help clarify the significance of MIN_TIME_FOR_USER_IDLE in this process?
(In reply to sdc.blanco from comment #43) Hmm. I didn't check , and only thought about E_POLL_TILL_AUTOSAVE_IS_ALLOWED (300 ms, which is used during UI operations like DnD, which may interfere with saving). MIN_TIME_FOR_USER_IDLE is indeed 10 s. On one hand, it's not ms scale; on the other hand, I still believe that 10 s is not worth mentioning in the help. So my advise would still be unchanged. Yet, looking at how it's used in the code, I feel it's implemented ... questionably. If I read it correctly: 1. When the normal autosave timer expires, the MIN_TIME_FOR_USER_IDLE will run unconditionally for all documents needing save (so the time will always become autosave interval + 10 s) - why? What prevents us from checking if "user is idle" already?; 2. When E_POLL_FOR_USER_IDLE timer expires, it will check if user was idle 10 s, and if they were not, it will start another E_POLL_FOR_USER_IDLE (ad infinitum!). So now I believe that there is a real scenario when the documents will not be saved - a test would be to press and hold a character key in Writer for infinite period, and see if this continuous typing would ever allow saving .... which is not good. 10 s idle period (actually up to 20): can we decide if waiting for such an occasion to actually save is OK? But - likely this is for a separate issue.
(In reply to Luke Kendall from comment #37) > I see there's a clear and good note about this now in the help page link Thanks for feedback. (In reply to Luke Kendall from comment #41) > "The timer is restarted at the first modification after each subsequent > save." iiuc (from comment 39) there are two different kinds of "save" that can happen in this situation. My proposal is to make those two kinds explicit by changing the sentence in question to: "The timer restarts with the first modification after the document or Autorecovery information is saved." @Justin L. Ok?
(In reply to sdc.blanco from comment #45) > (In reply to Luke Kendall from comment #37) > > I see there's a clear and good note about this now in the help page link > Thanks for feedback. > > (In reply to Luke Kendall from comment #41) > > "The timer is restarted at the first modification after each subsequent > > save." > iiuc (from comment 39) there are two different kinds of "save" that can > happen in this situation. > > My proposal is to make those two kinds explicit by changing the sentence in > question to: > > "The timer restarts with the first modification after the document or > Autorecovery information is saved." > > > @Justin L. Ok? It's maybe okay; I had to puzzle out what the Autorecovery information was. Maybe this might be even clearer: "The timer is restarted at the first modification after the document is saved (either by the user, or by an Autosave)."
(In reply to sdc.blanco from comment #45) > @Justin L. Ok? I still find the entire discussion to be irrelevant. Too much information. The document simply is saved after 10 minutes. That is all the end user needs to know. Assuming all goes well, it means the worst the user can lose is approximately 10 minutes of work. Exactly how it is currently implemented should be irrelevant from a user or documentation point of view.
(In reply to Justin L from comment #47) > (In reply to sdc.blanco from comment #45) > > @Justin L. Ok? > I still find the entire discussion to be irrelevant. Too much information. > The document simply is saved after 10 minutes. That is all the end user > needs to know. Assuming all goes well, it means the worst the user can lose > is approximately 10 minutes of work. Exactly how it is currently implemented > should be irrelevant from a user or documentation point of view. I find the discussion relevant, and the proposed information helpful. Admittedly, the situation now where the autosave time is measured for each document, based on its modification time, makes it much less disruptive than it used to be, and also now predictable. But to manage my work when editing multiple long documents with long save times, it's still helpful to know these facts, including when the autosave time is measured from. So I welcome the information, and the new implementation logic.
(In reply to Luke Kendall from comment #48) > But to manage my work when editing multiple long documents with long save > times, it's still helpful to know these facts, including when the autosave > time is measured from. And I agree with Justin, believing that this wish to know these details wouldn't arise at all, if not for initial bug, after which, the wish to understand arose. Now you know these details. It is irrelevant for 99.99% of the userbase (I bet my estimation of those who are interested is exaggerated several orders of magnitude).