Tried joe again recently after using nano, and one of the first gotchas i ran into was that joe asked if i wanted to throw data away. That is the polar opposite of what nano, and i dare say most programs, ask upon exiting with unsaved changes.
Edit: Seems that i was still using an older version, and said behavior has changed in more recent versions.
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).
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.
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?")
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".
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.
I was basically forced into using vi (school Solaris box with few editors installed and little space to compile more). A little muscle memory makes basic editing easy, and knowing the connections to "ed" helps things make more sense.
Easy stuff takes a small amount of knowledge, but more advanced features make the editor worthwhile for long-term use.
That was one of the reasons I gave up on using Joe for system administration. It showed rather big mismatch between my mental model of how a system editor should work and what Joe did.
Mh. On the one hand, the backup feature has saved my ass more times than I can count, but on the other hand for some software (hello nginx!) and their conf.d directories it can get nasty as well - not cool when you reboot the server and nginx doesn't start because there's a backup file with duplicate directives...
I would argue that scrolling is the sanest default for systems administration since text files are usually formatted to a fixed width and are sensitive to line breaks.
Yet try to edit with horizontal scrolling XML or JSON file written without line-breaks. Or perhaps some other config files written on assumption that a terminal window will always be maximized and get at least 200 character width.
In my opinion an editor for system administration should try to show as much information as possible by default and horizontal scrolling is an opposite of that.
