On Tuesday, July 23, 2019 at 3:15:44 PM UTC+8, Yakov wrote: > > Oh gosh, do you mean you had 2 subsequent saves with a little time gap > between them? (could you describe your scenario so that I'm more aware of > this potential problem? MainTiddlySaver hasn't debouncing implemented yet, > but I never experienced this problem with content, only with options > storage) If there's such problem, we should describe it in detail and refer > to this in future development; I wasn't expecting anything like this in an > extension saver (or may be the source of the problem is a bit different > from what you describe?) We really need a reproducible scenario. >
Yes, exactly. I enabled both autosave and savebackups so that I don't need to worry about any minor mistaken typings (you know we don't have a REDO right?). My TWC file is of >6M size so saving takes seconds to finish. savetidllers work like this way: When the user triggers a saving, it puts file name in the "debouncing" dict and will remove it from the dict once the saving finishes. But in several cases, it just doesn't removed my file name from the "debouncing" dict and then all my subsequent savings will just don't happen. I guess this problem will happen if I trigger successive savings with just a very short time period in between, although I'm not very sure. After several cases of catastrophic losses, I wrote a local crontab (macOS launchctl) script to monitor my backup folders to check whether subsequent backup files are of the same length (indicating that the main TWC file is not successfully changed). That's how I survived before Timimi+TWC appeared. Seems like BJ is the developer of savetiddlers? I suggest the author takes a serious look at this issue (if the author likes to maintain it in a long term) and I'll help to discuss about the reproduction. Anyway, I don't think "debouncing" is necessary. It does not hurt even if the user saves too frequently. So in my own (unsuccessful) modified savetiddlers, I simply removed this mechanism (Though it doesn't not work under FireFox 68.0.1). I don't think we need any documentation talking about this problem, because it happens just within a specific saver. Yeah, I second this proposal (thinking about it for some time already), but > this is a second level of IO improving which I'd address when a) I finish > making TWC saving async and b) some documentation about IO/developing > savers and editing (collaborating) workflow/infrastructure is established – > because this is a more complicated idea and is less trivial to implement, > especially when there's no docs describing it. > > Great. We can first make asynchronous saving work and then improves it. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/429382e9-5b9c-43f9-9225-040444b8a231%40googlegroups.com.
