Honestly the main reason seems to be that it looks less intimidating. Open vi and no help is offered in terms of commands, it's just an empty screen. Same for Emacs i think. Nano looks like something built for humans.

This is the greeting text that is displayed when you launch Vim [1]:

    VIM - Vi IMproved
    
    version 8.2.4133
    by Bram Moolenaar et al.
    
    Vim is open source and freely distributable
    
    Help poor children in Uganda!
    type  :help iccf<Enter>       for information 
    
    type  :q<Enter>               to exit         
    type  :help<Enter>  or  <F1>  for on-line help
    type  :help version8<Enter>   for version info
    
    Running in Vi compatible mode
    type  :set nocp<Enter>        for Vim defaults
    type  :help cp-default<Enter> for info on this

"No help offered" or "just an empty screen" is not how I would describe the above text.

[1]: https://github.com/vim/vim/blob/a96edb736d4274fc4aea46080078...

Most of the time I've seen people get stuck in vim is when they use "git commit" which opens up whatever you have $EDITOR set to. The default value in most distros I've used in vim/vi and I can't recall seeing usage help in that scenario.

I voiced my strong support when they changed the standard git editor on my distro from vim to nano. While I'm still playing with the thought of really getting into vim and/or emacs at some point, nano is just a much simpler, more familiar type of editor. Seems like a lot of other people also felt that way. Depending on your user base it might make sense to stick to vim though, in case you'd disappoint your more technical/unixy users.

I’ve always had the idea that EDITOR should be on the same level as the login shell on nix systems. Choose your shell and your editor when creating your account, or don’t complain about the defaults

I agree but I’ve found that a lot of users don’t know they can set EDITOR in their shell profile – or that the `chsh` command exists to let them change their login shell.

Yeah the “create your account” part of the install should expose a few more settings such as the above, or perhaps a more generic “user account settings” pane in the major DEs to show the most common environment configurations for user accounts

I am one of those that didn't know chsh was a thing - thanks for the tip!

True, but at least it points you to the :help command at the beginning of its man page and pressing ctrl-c tells you how you can quit.

As a Vim user I agree. People who don't know about this environment variable might also not be very familiar with Vim. It helps nobody to surprise people like that.

Also I like to use Vim's terminal buffer, and it turns out accidentally starting Vim inside Vim rarely leads to satisfying results.

What distros do you use? One of my ongoing irritations with Ubuntu is that the default editor is not VIM.

Y'know, now that you mention it, I don't recall changing the default editor in Ubuntu. I think I first noticed vi or vim as the default editor in Fedora around 6 years ago, and maybe also in git bash on Windows. Beyond that, my memory is hazy, but I think vi or vim is the default in Debian and RHEL/CentOS, but I wouldn't put money on it.

Just change it to what you want.

I do... every time :)

OP was specifically referencing vi, not vim

I have ended up in vim by accident on quite a number of occasions over the last few decades, but I have never seen the quoted text. Perhaps it is something you only see if you are trying to use vim on purpose?

The Emacs welcome screen links to a tutorial, a guided tour, and manual, all of which are inside Emacs. I would say its help functionality is potentially its greatest strength.

Right, but when nano first opened for me, I didn't need a help or manual. That's what I mean by it feeling like it was made for humans.

I use nano when I need to edit something from CLI because I don't like ancient editors with modes or non-standard key combinations from 80s. And in nano the most important shortcuts are at least written in the bottom of screen.

While nano supports some standard shortcuts (arrows, Ctrl + arrows, Home, End, PgUp, PgDn), others are non-standard and I don't understand why. For example, "save" is Ctrl + O instead of common Ctrl + S, exit is "Ctrl + X" instead of "Ctrl + Q", Esc doesn't work when you want to cancel search, and so on. What a nonsense. Why should someone use different shortcuts for the same function.

It's not a good idea to use Ctrl + s and Ctrl + q as default keybindings for any important functionality on the terminal because terminals traditionally used them to stop/resume terminal output. Some terminal emulators still do this, so making people press those keys unwittingly would be problematic. So no, nano developers aren't being non-sensical here.

Yep, pressing Ctrl-S in a terminal and having it freeze up is extremely confusing at the best of times. Because I often (used to) press Ctrl-S as a reflex against certain crashy software, I'd not even really recall pressing it and then I'd wonder what the hell was going on.

Then again, I have saved :wq into a few text files too!

> Yep, pressing Ctrl-S in a terminal and having it freeze up is extremely confusing at the best of times.

At least some terminals (IIRC, KDE's Konsole is one of them) show a helpful colored bar telling you that the output is paused and you should press Ctrl-Q to resume. Unfortunately, other popular terminals (like Gnome's gnome-terminal) don't have any visible indication for that.

‘stty -ixon’ disables this.

This made me chuckle. Pico was the first non-BASIC editor I used because the public library BBS used Pine. As a descendant of Pico, I'd say that Nano is an ancient editor, and it comes with all the historical baggage fueling your complaints.

Actually, ^S does save, since 2017.

But you might have to put "stty -ixon" inside your .bashrc (or does nano take care of this?).

Nano takes care of this, just like it disables line buffering (ICANON) and signal keys (ISIG).

Back in the 90s the joke was "Eight Megabytes And Constantly Swapping". 8mb is nothing now and I note that Nano, with no file open, is 6768kb virtual and 3620kb resident on my x86_64 Linux box.

(I use mg as my small emacs alternative; full emacs UI but tiny binary / memory. Unfortunately it doesn't support Unicode properly.)

Modern operating systems and memory allocation techniques make it hard to account for memory usage in a meaningful manner without a more in-depth investigation of program behavior. Quick stats from memory reporting tools aren't worth much in isolation unless those numbers significantly deviate from expectations.

I wonder how much of the base data structures that are always in memory are pointers, and if it'd be more fair to say it's really the equivalent of 3 mb virtual/1.5 mb resident (or even 1.5/.75 for 16 bit!)

Check jmacs from joe.

Oh that's nice, somehow I never thought to try Joe. It's 13MB VSZ and 7MB RSS megabytes in my little measurement. emacs-nox is 94/22.

"emacs -nw -q" can be pretty fast too.

Not light on resources compared to jmacs, but at least it loads faster.

There is also GNU zile.

Or Mg, which is even smaller.

The parent had issues with Unicode, which jmacs doesn't.

Does not support Unicode.

> I never really understood why Nano was so popular when you could use Emacs

> When I bork Emacs and it doesn't work

Only 50 % joking but like you said it's not if, it's when. Nano is there and works.

`emacs --quick`?

emacs -q

Nano is _by far_ easier to use as a first-timer on the command line. Emacs is an amalgamation of a scripting language that happens to have a text editor built in.

5. Sometimes you don't need an operating system, but a decent editor and that's where Nano come in :)

I used to use jed instead of nano for quick edits, but same idea really. Then one day I realized that "emacs -nw -Q" starts subjectively instantly, and is also immune to a borked configuration ("-Q" skips it). So I just created a short alias for it and use it. Bonus: one can always load all the configuration later if needed.

That doesn't solve point 1 obviously, but then that's never been an issue for me: emacs is always where I need it, and then there's always TRAMP.

> Emacs isn't always on all the systems

Nor is nano.

vi is about the only editor that can be assumed to be available on a unix-like system.

Ed is the standard editor

An editor with always-on help displaying the most common actions one might want to perform, is super-useful not just for n00bs, but for anyone who doesn't work on the command line enough to memorize the commands to operate vim and emacs.

Crucially, you don't have to ask nano for help. It helps by default.