When you accidentally make edits to an old note, and undo the changes, the modification date is not updated back to the original one. Is this expected behavior? It’d be great if the modification date reverts back since no modifications have been made.
2 Likes
I’m not sure why these are your expectations but this can’t work in a context where we have to automatically save the note context when the app is idle.
I was merely asking a question.
Still, many macOS document-based apps behave that way, including TextEdit and Bear’s own Panda. an “Edited” tag appears whenever a modification is made, but it disappears if changes are immediately undone. The modification date remains unaltered when the document is closed.
While I appreciate that Bear is not a document-based app, it does behave differently. The modification date changes even if the edits are promptly reversed. Although I acknowledge that this is a design choice by the Bear team, the assertion that “this can’t work” seems overstated.
Given Bear’s commendable attention to detail, I felt it worthwhile to mention this minor issue. Had I anticipated a dismissive response, I would not have bothered. If my question was unwelcome, I am content to let the matter rest.
1 Like
+1 I don’t think this is an unreasonable request.
the assertion that “this can’t work” seems overstated.
I’ll try to explain better. TextEdit and Panda have a file-based approach without autosave in place. Shoebox applications like Notes usually autosave the content of the note after a period of inactivity or when you switch to another note or another app, … This means the note is also updated online when it (auto)saves.
Now, imagine a situation where you are writing something, and at some point, you have to stop for whatever reason. Your note was saved but now you want to roll back your edits. In this situation, the modification date is the last time the note is saved not the modification date the note had before saving.
This is why.
1 Like
I appreciate the clarification.
It’s worth noting that document-based apps, a.k.a. file-based apps, like TextEdit and Panda do implement an autosave feature. After editing a note, if a minute or so passes, these applications automatically save the note. If changes are undone at this stage, the modification date isn’t rolled back. Thus, you have a window of less than a minute to undo changes without altering the modification date.
This particular behavior led me to infer that it is a design choice, one that revolves around the definition of a ‘period of inactivity.’ This inference is also the reason behind my use of the terms ‘immediately undone’ and ‘promptly reversed.’ It appears that Bear’s current design defines a period of inactivity as less than a second because the modification date changes even when I reverse the edits as swiftly as humanly possible.
I can understand if this design choice was driven by the aim to prevent any loss of content. It’s a valid concern - no one wants to lose their work. I, too, would advocate for a design that emphasizes loss prevention over maintaining the modification date. But Apple, interestingly, seems to have found a suitable autosave interval that allows for immediate undos in. This led me to wonder if Bear’s autosaving interval could be adjusted in a manner that balances both content loss prevention and the allowance of immediate undos.