Dear Benno!

I can confirm that the patch is a good solution from a programmatic point of view!

---

However, from a behavioural / linguistic point of view, the phrasing of the message shown can still trip the user very easily into pressing No when they should be pressing Cancel instead.
Consider this scenario:

> Nano: File modified since you opened it; continue saving?"
> User: Oh, shit, I'm about to overwrite something potentially important. So, NO, I don't want to continue! Stop!
> User: (presses 'No', unintentionally discarding all their hard work)

In other words, the phrasing "continue saving?" makes the user instinctively answer 'no', with the intent of aborting the 'overwriting'. But they end up "not saving and then proceeding to exit" instead, potentially losing important changes.


In theory, the least-work change would be to change this message to something that would be more or less compatible with both a 'save-on-exit' scenario as well as a 'plain-save' one, e.g.:

> File modified since you opened it; continue saving? ('Y' to overwrite, 'N' to ignore saving, '^C' to abort operation)

But, having said that, I think what would make the most sense would be to create a brand new message for the specific case of save-on-exit. E.g. something like:

> File modified since you opened it; continue saving? (Note: 'No' will exit without saving!)

---

Also, as a minor thing. While the second patch seems more sensible, the comment on your first patch made it a lot easier for me to understand what was going on and follow the code. From a "help newbies read the code" point of view, it might be nice to add a comment or something next to what the choices do in that context :)

e.g. :

if (choice == 1) // 'Yes'
else if (choice == 0)  // 'No'
else if (choice < 0) // 'Cancel'

(you have a similar comment in search.c, from what I've seen)

---

I think attached patch fixes the problem.  Please try it out.

(file #52703)

Assume the following scenario.

0. You open 'file.txt' in nano (instance #1)
0. Without exiting #1, you open 'file.txt' in nano again (instance #2). #2 informs you that the file is already open and asks you to confirm if you really want to continue editing. Select yes.
0. Make a change in #2, save normally and exit.
0. Make a change in #1.

At this point, if you press Ctrl-X to exit, hoping to be prompted to save any unsaved changes while exiting, nano does the following

0. Save modified buffer?  (press yes)
0. File name to write? (confirm 'file.txt')
0. Nano will inform you the file has changed on disk and ask you if you want to save anyway!

At this point, expected behaviour would be:

- Press 'Yes' if you want to save anyway, overwriting any changes made externally.
- Press 'No' if you want to exit, discarding all local changes (and thus keeping the external version).
- Press 'Cancel' to abort EXITING, and continue editing (possibly to save a backup of the local version without tampering with the external version).

Instead what happens is that both 'No' and 'Cancel' exit nano, discarding all changes.

---

== Why is this the wrong behaviour?

Programmatically, this behaviour makes sense. If you've reached the "save file?" dialogue, if you say 'no' or 'cancel', it will abort ONLY the 'save' action, and continue with what it was doing before, i.e. the 'exit' action.

However, this is not meaningful in the above scenario. If you are about to save a file and you are confronted with the 'file has changed on disk' message, and you are not sure how, the most natural thing to want to do is to abort the exiting part (not just the saving part), and while nano is still open, attempt to save a backup under a different name, so that you can 'diff' this against the file on disk to see what changed and if it's worth keeping / merging the difference.

As it is now, even if you press "Cancel", nano will still exit and you will lose all your unsaved changes. I would treat this behaviour as a bug.