search

typora / typora-issues

Bugs, suggestions or free discussions about the minimal markdown editor — Typora
https://typora.io
1.53k stars 58 forks source link

File modification date should not change when dirty file closed with Typora #6052

Open neuromachina opened 2 months ago

neuromachina commented 2 months ago

Describe the bug When I open a Typora file the finder indicates the modification time of the file was changed.

To Reproduce Steps to reproduce the behavior:

  1. Open previously saved file
  2. Note that the modification time changes

This is unexpected behavior.

File mod date should not change.

Use BBEdit as an example of proper behavior.

Desktop (please complete the following information):

Typora Version 1.8.10

This has been an issue for more than one year... maybe two years.

Super annoying. I've just been putting up with it because I believe authors words that they want to build a perfect product. Please ficx this as high priority. I depend on my file save dates as a record keeping attribute.

When I open a file for reading, I DO NOT EXPECT THE MODIFICATION DATE TO BE UPDATED to match the last day I opened the file for read-only.

Thank you!

abnerlee commented 2 months ago

Could you attach the sample md file? May relates #2354

neuromachina commented 2 months ago

Hello.

I was unable to reproduce just now. Any text.md file.

My issue that I believe I have experienced many times before is a file's modification date was changed when a file was opened and perhaps edited (maybe not?) but not explicitly saved (for sure). I looked for an option to turn off auto-save.

I probably described this incorrectly in my first message on this Issue.

Our family purchased two 3-packs of the Typora license. We appreciate the design sensibilities in the UI. Just so you know, I respect and value the commitment to make a sw product as bug free as possible. Typora is both elegant and functional.

Thank you.

neuromachina commented 2 months ago

After I tried to reproduce, I experienced one problem that is not advisable according to Apple User Interface Guidelines. That is, if the file is dirty, an attempt to close the file could result in data loss if the User was not asked if they want to save the new edits to a file. And in this case for me with Typora, an inverse, a data loss scenario is existent when the developer decides to auto-save a file (with no option for the User).

If the context of this auto-save is after a block of important text was inadvertently deleted before this save event, then there will be data loss IF the User cannot intervene to make the decision "not to save the file" in its current state. And presumably the user would perform an Undo command in that situation to restore the file to the previous state (and the current state in the file system).

AFAIK, BBEdit will track all those changes and if the file gets back to a state that matches the saved version in the file system, then BBEdit will no longer consider the file dirty and will close it without prompting the users that it is dirty; because it is not.

So this is definitely a sharp edge in the UI that can cut. It would be best if an auto-save-on-close workflow did not exist as a default with no option to opt-out.

If you want to be in the macOS Application Hall of Fame then consider an auto-save toggle in the Application Preferences such that Users that don't want that can turn that on.

I like auto-save in my Jetbrains IDE but not in my Typora files.

You are definitely on the trajectory for Best in Class application with the work you have done so far.

Please make prudent considerations when adding features that are better solved by other tools that do one thing well. I am thinking that you already think that way. :-)