original discussion: https://github.com/l3kn/org-fc/issues/35
I think the hardest part about this is chaning the entry in the review history file, as it can grow pretty large (18mb, 143k lines in my case) so loading it to change the last line takes some time.
Why are you using TSV for the review stats, by the way? You could use a sqlite3 database instead, after all. Using a sqlite database should make the speed of undo feasible.
I chose TSV for the review history because:
- It avoids adding another dependency (sqlite, emacs-sql)
- It's easier to work with using e.g. Python or R
- It works well with version control (git)
I've already changed the review logic to collect ratings in a list, only writing them to the history file after each review.
This should be enough to implement an "undo rating" feature, because we can just select an entry from this list and change it.
On 8/9/20 1:45 PM, ~xyank wrote:
I think the hardest part about this is chaning the entry in the review history file, as it can grow pretty large (18mb, 143k lines in my case) so loading it to change the last line takes some time.
Why are you using TSV for the review stats, by the way? You could use a sqlite3 database instead, after all. Using a sqlite database should make the speed of undo feasible.
I've already changed the review logic to collect ratings in a list, only writing them to the history file after each review. This should be enough to implement an "undo rating" feature, because we can just select an entry from this list and change it.
Is this already done and committed to the main branch? If so, I'll take a shot at implementing this feature.
Is this already done and committed to the main branch? If so, I'll take a shot at implementing this feature. Yes, the org-fc-review-session class (org-fc--session) has a :history slot.
Entries are added to it in the
org-fc-review-update-datafunction. If it works better for you, you can change it so it stores number / float value and only formats them when writing to the review history file.