Perhaps you used Ctrl-C, which means abort. The message is there to prevent you from accidentally discarding your file.

If you use Ctrl-K Q, then it works the way you expect. Notice that it says "Hit Ctrl-K Q to exit or Ctrl-K H for help" when you first start the editor. I added this beginning with version 4.2 for this very reason.

Also, if you try "jpico" JOE further emulates nano (pico is nano's predecessor).

Ctrl-K Q still produce the "lose changes to file" wording, indicating that a Y answer is backwards from what i would consider the norm these days.

I know Yes/No remains very usable in a terminal, but seriously, why is there not consensus about the question of verbs vs Yes/No alternatives in dialogs yet?

I always thought the verbs were obviously better. Better the quicker you're reading the dialog, and most users don't bother reading it all.

To be clear with what I mean:

1. Do you want to save your data before exiting?

[Yes] [No] [Cancel]

2. Do you want to save your data before exiting?

[Save] [Discard] [Cancel]

For GUIs I 100% agree it should always use verbs. For command lines I think there's a very long history of confirming destructive things and allowing for /usr/bin/yes, so verbs don't quite make sense.

I think GUIs took so long coming around because of the command line.

The question "Do you want to save" on exit (which some software asks) is destructive when answered "no" (you lose shat you've typed and efited). I've always found it wrong, as in most other cases answering yes is destructive ("do you want to format?")

It's effectively a different way of asking "Are you sure?" where the affirmative continues.

Which version of JOE? It should say "File fred has been modified. Save it (y, n, ^C)?"

Maybe you have a .joerc file in your home directory with the old bindings.

Hmm, it may be that the repository had an old version. I'll try looking for an update.

I mostly live in my IDE and its editor doesn't have a concept of unsaved changes and doesn't ask. Meanwhile it has undo/redo, browsable local history and VCS integration. What's the benefit of having changes unsaved?

Don't you ever go into a file, start playing around with an idea, decide you don't like it after all, and want to revert to the on-disk version? That's probably my most common use of leaving changes unsaved.

I don't know what editor the GP is talking about, but I would love an editor which had some sort of persistent edit-buffer. So, my work is always saved somewhere, and simply committed to the file I'm working on when I click "save".

Between undo, local history and VCS I have exactly that, but much more too.

I don't see the benefit of the editor saving the file to disk without being told to. My editor has that feature too (although it's not active, by default), and I've never understood why that would be desirable.

A lot of what I do is under version control, but not everything is, and a 3-character "revert buffer" command makes more sense to me than a longer VCS command that will also discard changes that might already be present in the on-disk version of the file.

It just strikes me as a feature where I'd have to rebuild my basic assumptions of how an editor works, without the incentive of a worthwhile improvement to the workflow.

My editor does this independently of VCS, so that's not an issue. I get it, "last saved to disk" is a save point that is meaningful to you. The world you can move to is a world where you can have any number of these save points. "last saved to disk" would be "go back ten minutes" but you'll also "go back five" or whatever else. It's a much more general way of working.