Option to exit without saving the file

[bartart3d]

I noticed a peculiar and somewhat weird behaviour in the 'exit the program' strategy. I think I know why: to prevent data loss but working like this might cause the opposite. When exiting the program there is no way to 'not save', which seems like not important, but it is.
I have already tried out Manuskript where some actions cause corruption of data. I only could prevent it to happen permanently by 'not saving'. If this happens in novelWriter, I only have two options, exiting by killing the program manually (cli) or powering off the computer: not good.
The data is 'sacred', do everything you can to prevent the software to lose it, and it might seem contradictory, but having the option to 'not save' can be a chance to save data!!

Also, sometimes, when writing for a while and being not happy about the result and quickly quitting, having to revert your changes manually before exiting is way too tedious.

[vkbo]

This is partially a duplicate of #494, but I'll address it again anyway because this one has a few extra points, so I'll make it a bit more detailed response so I can refer to it later if it comes up again.

Unlike most single-document editors, a project in novelWriter isn't loaded into memory as a whole when you launch the app. The project itself is just a virtual file system that corresponds to a file hierarchy on the disk. Each file corresponds to a text file on the disk, and aside from being listed in the project, they are separate objects. It is more accurate to view the project tree as an extension of your file explorer. The latest state of that structure is saved to disk on a timer and when you close. Not doing this, with the way the project manager is designed, would frequently lead to inconsistent projects.

When it comes to files, each individual file you work on is an independent file on disk. When being edited, these are loaded into memory and kept in their altered state until saved like in most text editors. Currently, the document is saved automatically on a timer and when you close it. It is possible to add options to switch off these automated behaviours and insist that the user manually saves the document. I can certainly look into this.

I can't say much about how other writing apps handle files. I've tried a number of open and closed source writing apps, and encountered a variety of ways data is handled and saved to disk. Some use a single file of some archive format, some use a hierarchy of files like novelWriter does. I've modelled the behaviour of novelWriter on a mix of those I felt handled these things in the most robust manner.

The entire point of how novelWriter handles files and projects is to prevent data loss. This has been the prime driver between every design decision when it comes to how data is handled. I'm fairly paranoid about losing my work. If novelWriter crashes, you may lose the last few seconds of work (you can set the auto-save interval to whatever value you're comfortable with in Preferences), but unless the file system fails, your data is saved via a temporary file and only replaces the old data when the process is successfully completed. If novelWriter crashes during saving, such that a new file your working on is saved, but the project structure is not, the next session will try to restore the file meta data and put the file in an Orphaned Files folder for you to find and recover.

Reverting Changes

I do see the point in being able to revert the changes you've done on a single document since you opened it. I think it may be a better option to have a feature that can revert it rather than interfere with the save functionality, but having options to disable the auto-saving features are a solution too.

I am also planning to add a versioning feature that allows you to revert files to a previous state where you yourself choose the checkpoints. This is discussed in #383.

[vkbo]

I've thought about this suggestion a bit more, and I believe there is a middle ground here that is fairly straightforward to implement.

Firstly, not saving the project XML file is not an option. It would certainly cause a lot more problems with regular use than possible corner cases it may resolve. However, the save process will always keep a second copy of the project in an nwProject.bak file, so recovering from a broken project is fairly straight forward, and in case of an invalid XML file, also done automatically.

Secondly, allowing the user to choose whether to save the document currently being edited is far simpler (your last point). It can be achieved by making the auto-save process separate from the regular save process, and let the user decide via a setting in Preferences whether the full save is done automatically or manually. In the latter case, a dialog box would ask before a file is closed. Currently, it doesn't. The file is just saved.

The second point here is easy to implement as it can be achieved with a couple of if-statements. It will require some logic to be added to handle restoring files in case both a fully saved and an auto-saved file exists at the same time, which may happen in the event of a crash or a power loss. That isn't a big deal to implement. Such logic already exists for the project file.

At least this will partially solve the request, and give the user the option to choose the approach.

I've also looked at the code for how Manuskript handles saving the project, and it seems to be quite different and more centralised, with a final set of writing a single archive file as far as I can tell. novelWriter doesn't have any of that. Just one XML file for all the meta data of the project structure, and each document as a separate text file. These are completely disconnected aside from a reference to the key of each document stored in the XML file. All other files in the project folder are non-critical and are mainly cache files (JSON format) that can be regenerated.

Edit: I'm adding this to the list of features for version 1.1.

[vkbo]

I haven't forgotten about this, and I have tried to make the automatic saving of text documents optional. However, it goes against the current flow of the code, so interrupting this process caused a lot more issues than I anticipated. I've abandoned my attempt for now.

As I've mentioned, the current flow of how files and data is handled is written very deliberately to prevent loss of data, even during a crash. I don't think it is something I want to rewrite at this point. The data handling process doesn't have a single point of failure, like zipping up temp files into the final file container like many other programs do. I've designed it much closer to how I'm used to code editors working.

I still think the ability to revert the changes made in a session is a good feature to have. I solve this myself by tracking all writing projects with git. I think this is best solved by version control, and plan to make it a part of the built-in versioning feature. I want to make the versioning feature automatically keep the n last versions of a document on a session basis, where n is a user-defined number of copies. The versions will be rolling, unless you decide to tag one for keeping. Perhaps even define a percentage change threshold for automatic flagging as permanent. I also plan to make use of the built-in difflib library in Python to provide a simple diff tool for file changes.

[johnblommers]

Let me wholeheartedly agree that re-inventing the wheel isn't a good use of resources when we have Git. Some novelWriter-Git integration makes more sense to me.

[peter88213]

I have read through your arguments and want to make some suggestions.

First possibility:

• When opening a project, create a working copy in a temporary directory.
• When closing with Save, rename the original project to backup, and save the working copy as a project.
• When closing without saving, delete the working copy.

Advantage: the existence of a working copy at program startup indicates an irregular exit at the previous session.

Second possibility:

• When opening the project, create a backup copy and work in the original project.
• When closing without saving, overwrite the project with the backup copy.

[vkbo]

First option:

That is essentially the functionality of #977. However, it undermines the robustness principle of the text content being independent of the session and the project structure itself. It would therefore have to be opt-in. Release 2.0 introduces core functionality that is intended to support such changes at some later point.

Second option:

That is the intention of the automatic backup solution already in novelWriter. The only difference is that you'd have to extract the zip file yourself to roll back. I've considered adding a dialog box where you can do this though. It is essentially versioning by full snapshot.

[peter88213]

That sounds good. Then the irritating pop-up on program termination could be omitted? It follows a logic that is exactly opposite to the usual one, namely not forgetting to save.

[vkbo]

The pop-up is there because people tend to assume novelWriter works like a word document where the project doesn't exist on the drive until you save, as opposed to like a code editor where each files corresponds to a file on disk and is always there once it's been created in the project. It also prevents accidentally closing the project, which is less of an issue.

That doesn't really change here. But if the confirmation box is annoying, please suggest a better solution.

[peter88213]

Well, one principle of good UI design is to require user interaction only when there are choices. I mean, real choices.
I think that after a short time the serious users of novelWriter will understand how the auto-save thing works.

If you want my opinion: I would align the program logic with what is common, that is, let the user consciously save the changes.
But if you don't want it to be like that, you could put a "Don't remind me again" button in the pop-up.

[vkbo]

I would dispute that "common practice" somehow is "best practice". I find most text editors to be annoying because of these constant interruptions in my work flow. The fact that my work isn't just saved generates a lot more friction than the opposite approach to assume you do want your changes saved. The most relevant comparison here is code editors, due to the multi-document structure, and accidental unsaved changes is almost a daily cause of friction and wasted time in my day job.

The case of wanting a roll-back is the exception rather than the norm, and is covered by having snapshots you can restore from. That is also the motivation for the versioning feature, but I think a light weight solution based on the already existing backup feature is the obvious solution to this.

As for the dialog box, the option it gives you is the option to cancel closing the project. There are actually two of these. One for just closing the project, and one for closing the app. The former is perhaps redundant since it is difficult to accidentally close the project, but this is not only application I use that asks for confirmation before shutting down entirely. I could limit the dialog box to only pop up when it is done through the keyboard shortcut though. Accidentally hitting Ctrl+Q is probably the most common cause of unintentional exit.

[peter88213]

Sure, it's your show. With writing software, I've actually seen the autosave feature more often. So also with yWriter, which however does not show a popup on exit.

[vkbo]

I'm happy to do something about the pop-up. I don't really like it myself. It is only there due to feedback from users who were confused about what was and wasn't saved. The LED icons on the status bar are there to indicate exactly that, but maybe many don't notice them. Ideally, I would like no interruptions under normal operations with the exception of blocking accidental disruptive actions like accidentally hitting Ctrl+Q.

[peter88213]

• As mentioned earlier, you could make the message optional. For example, with a "Do not remind me again" checkbox.
• Another idea: Bind the confirmation only to Ctrl-Q key combination, and not to the general exit routine.

[vkbo]

• As mentioned earlier, you could make the message optional. For example, with a "Do not remind me again" checkbox.

The dialog boxes don't allow for that, so I'd have to make a custom one, but it's definitely an option. I think that may be the best solution.

• Another idea: Bind the confirmation only to Ctrl-Q key combination, and not to the general exit routine.

You don't get credit for that idea, since I already mentioned that 4 posts up!

But, permanently dismissing the dialog box is probably a better idea. I could use it for other boxes too. The backup dialog box has a setting in Preferences to disable it, but I suspect most people don't know that.

[vkbo]

Feature request #1470 is technically a duplicate of this request, but the implementation summary there is much more in line with other planned features of novelWriter that are upcoming, so I reopened it and scheduled it as planned. I will close both these threads at the same time when the features of the other one are implemented.

The implementation details are spelled out there. However, here's the gist of it:

• I will add a single file storage option for novelWriter projects. See Single file format (again) #977. The feature will at first be opt-in, then later be opt-out. (I will not remove directory based projects in the foreseeable future.)
• When single file storage is used, the working copy at runtime will be an extracted folder of these. Either in some user app dir, or as a hidden folder in-place.
• Since the zip file will have to be created on save, I can easily pop up a dialog box and ask first, which will satisfy the criterion here. I can also easily allow manual save (Ctrl+Shift+S) to bypass this check, but not autosave.
• The functionality of folder based projects will remain unchanged though, but it is likely that people who stick with the folder format will do so because they use version control (like I do myself) and therefore resetting changes is trivial anyway.

[vkbo]

I'm closing this since it will be implemented as planned in #1470. These two issues are linked, so it shouldn't be a problem.