Hacker News Reader

Comment by hsnewman | Hacker News Reader

I've been using joe for over 25 years, I just like how easy it is to use.

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).

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.

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 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.

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.

For me, over a decade. It's simply easy and does not pull any confusing tricks like nano with long lines, or vi with... incomprehensible behavior.

Everything seems incomprehensible until you comprehend it.

My one use for vi is to edit /etc/joe/joerc to enable -nobackups.

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.

We will continue to debate making nobackups the default, but what other behavior is wrong for system administration?

Scrolling, not wrapping, of lines that do not fit screen.

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.

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 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.

Having cut my teeth on Turbo Pascal 3, I quickly adopted Joe when I started using Linux around 1995. Most of the same key mappings were there.

I'm a bit surprised to see it still is around. I eventually switched to vi, since it was reliably available on most systems.

Precisely why I use Vi(m) today. Maybe it’s not the best, but it seems available on just about everything.

Reply on news.ycombinator.com