google
Redos not saved
The redoChain doesn't seem to be saved anywhere. I'm intending to handle this in #10 using cPickle.
Actually, will create a new PR for this and make respective changes to #10 after if needed.
Doesn't #12 cover the bug? Also, right now we have all the data stored in a history.dat file. I'm thinking maybe we should have a new pickle file for each new document instead of an all in one just so accesses are faster and there are no conflicts. However, this brought up the question of how to delete these files, since it'll end up building up. Should we just leave this issue to the user and let it build up? I don't think it'll take a lot of space so it probably won't be a problem, but yeah, just a heads up.
If we end up doing the all in one, I was going to make the file name of each document the keys for a dictionary and each of them have their own dictionaries. There's also the problem of what happens if the user creates another document with the same name, there's no UUID for each document I don't think?
fyi/headsup: after merging the PR to fix truncating the redoChain, I moved the Mutator class into its own file.
Oh alright thanks for the heads up. Do you have any ideas on how we should be implementing this problem by the way?
Lots of thoughts. Too many.
There's a choice of whether to store the undoChain (and then how to store it) or to store a revision history.
There area storage choices, such as:
- pickle
- json
- custom text log
- custom binary log
pickle
pros: existing format, fast cons: opaque to inspection (debugging)
json
pros: existing format, open to inspection (debugging) cons: not fast, someone might try to edit it (creating unexpected bugs)
custom text log
pros: fast (append), open to inspection (debugging) cons: someone might try to edit it (creating unexpected bugs)
custom binary log
pros: fast (append) cons: opaque to inspection (debugging)
Alternatives to saving the redoChain
We could also store the edits in a format that is independent of how the changes were made.
- use an external revision tool (rcs, cvs, svn, git, etc)
- use an internal diff tool (libdiff)
In this style, the 'undo/redo' is really a history of changes and 'undo' is checking out to an earlier revision.
I'm still trying to figure out how we would keep all the saved data efficiently. I was thinking of maybe making a dictionary with the full path of the file as the key, but that means if the file is moved or renamed, we now have a dead entry. We could also simply use the name of the file as a key, but that means if the file is renamed we'll still have a dead entry or if there are two or more files with the same name, we'll have conflicts and can only save one.
I really like this idea though, so I don't want to give up on it yet. Maybe we'll have to just make some concessions. For example, we can use the full path since people don't necessarily move their files all the time and maybe check the dictionary for dead entries when the user exits the program.