GNU Nano 6.3 | Hacker News Reader

GNU Nano 6.3

nano-editor.org

147 pointsmarcodiego109 comments

As an Emacs user I never really understood why Nano was so popular when you could use Emacs, but I've since learned a few things...

1. Emacs isn't always on all the systems, and getting it downloaded/setup can be a pain in the butt

2. Sometimes it's just easier to launch nano quickly to edit one line in a .bashrc from the command line

3. When I bork Emacs and it doesn't work, it's nice to be able to fall back on a simple editor to edit my .emacs.d

4. It's nice to have an alternative to vi with keybindings I'm more familiar with

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.

One of my former co-workers loves Nano. It does what he needs, it was installed on all our systems, if not it is safe to just apt-get install it. Most of our documentation said this like "edit this line in this file, using: vi <path to file>." Every time he wrote documentation, or updated existing, he'd change "vi" to "nano".

It always makes me smile and think about him when I spot "nano" somewhere in the documentation.

Nano's great advantage over vi(m) is that you can instantly see how you can save the current file and exit the editor, e.g. when confronted with it because of a "git commit" on some server. So, if you configure an editor that anyone should be able to use, I would prefer Nano too...

> Every time he wrote documentation, or updated existing, he'd change "vi" to "nano".

It might be better to change it to "nano -w" instead; IIRC, some versions of nano hard-wrap lines by default (which corrupts files where line breaks are significant) unless you remember to always use "nano -w".

You can add a "set nowrap" line into your home ".nanorc" file so "-w" is applied by default.

Relying on configuration, either in your home ".nanorc" or in its /etc equivalent, is too risky; you might be using ssh (or docker/podman/etc) to a machine or VM or container which doesn't have that configuration. It's the same for relying on having a nano version where that's the compiled-in default; you might be using a machine or VM or container with a different nano version than you're used to. It's less risky to always type "nano -w" everywhere (or use a different editor, one which never had hard-wrap enabled by default in any version).

I am teaching my 10 year old Python using Nano, and he’s picked it up surprisingly quickly. When I wanted him to upgrade to VS Code, he preferred the terminal! Nano’s a great product, thanks for the hard work on it all.

Sounds great. Starting small makes sense. I wrote my first code in MS Notepad. Then used Notepad++. I use VS Code these days but can’t see what it would have done for me as a child.

So much fun in this editor. I'm surprised it is getting so much regular development. A breath of fresh air, it has helped edit many config files on remote shells.

Since I discovered micro[1], it's my go to editor.

[1] https://micro-editor.github.io/

Another Micro advocate! I agree, it's also my go-to editor. It's a great halfway point between breaking out Emacs and resorting to Nano. Micro is dead-simple and gets work done without any complication.

micro > nano

If it's not vim or emacs, a simple editor with CUA key binds should be the default everywhere, not nano.

I love it.

In Micro, selecting text using shift with left/right arrow works (across lines too), but is there a way to make it work when you press up/down arrows? And how do you shift select to the end of the line?

Works as usual for me (I am on a Mac). shift+up/down selects lines. shift+fn+right -- selects till the end of the line.

Thanks, hmm, so shift up/down deselects anything that was selected for me. Shift left/right works and mouse select works. Shift+fn+left/right makes me switch tab. I'm guessing my keyboard shortcuts are different compared to your setup but I don't remember changing anything here (using the regular Terminal app for Mac).

From an editor that most people can exit to an actually powerful editor on its own right, nano has definitely evolved from just being a pico clone.

It's really nice for config file editing if color-coding is enabled and supports the config file you're working on.

Doesn't emacs have a nano mode?

Regardless emacs can take long to boot up (unless you invoke it with -Q) but nano is instant. So when I need to change one line of a file real quick, nano is the better tool imho.

I launch Emacs when I log in just after booting. It restores its desktop (all the frames and buffers) and I never close it. Even though it has to restore a couple of dozen buffers and nearly that many frames it takes only a few seconds anyway.

As I am in Emacs anyway opening a file is very fast unless it's a really large file, multiple giga bytes.

Why would anyone close Emacs? Do you close the web browser too? What about X Windows?

Even without a server, modern Emacs can load quite swiftly by making use of deferred loading on demand. I stopped using an Emacs server some time ago because it loads fast enough, now.

I haven’t used Emacs in a few years and I don’t remember the startup time being a problem. Maybe because I always left it running?

Anyway, I looked up what people are saying these days. Looks like maybe a second or two?

https://www.reddit.com/r/emacs/comments/m8d55l/what_is_your_...

Setting up emacs server pretty much solves this problem as each subsequent launch uses the same running daemon. After that you just set up an alias that launches emacsclient like the following:

alias editor='emacsclient -t'

alias visual='emacsclient -c -a emacs'

Unfortunately, I don't expect to have emacs server running in an EC2 instance intended to run a company service since it needs to be a copy of prod instance (for testing/development). In such instances nano is helpful.

Ah, yes that is where tramp emacs package comes in handy, as it allows one to edit remote files within your local instance of emacs.

Note there is also helm-aws [https://github.com/istib/helm-aws] for managing AWS EC2 server instances directly from Emacs.

I like JED for that.

Maybe you can get one. I don’t see a nano mode in MELPA or GNU, and it doesn’t ship with Emacs. Nano is also much more likely to be installed than Emacs, especially since Apple stopped shipping Emacs with macOS.

Apple also stopping shipping nano with macOS (as of 12.3) and went back to pico.

Huh, interesting. Nano is symlinked to pico. I never noticed, since I don’t use it.

GNU Nano is GPLv3 which Apple boycots (its v3 since 2007 according to Wikipedia). Tells us GPLv3 works :-) not sure what the license of Pico is. My first text editor was Q&A on MSDOS, it relied on F-keys, and on Windows 9x I got used to ctrl as modifier. Pico/Pine and later Nano was a natural successor, easy to learn. I use Vim and ST now.

> not sure what the license of Pico is

Apache 2.0. I've used pine as a mail reader for well over two decades at this point, mostly on big old UNIX boxes. GNU nano always felt like the knockoff version.

Right,it got relicensed. Originally it was not available on e.g. Debian.

I don't even think Pico is in active development any more.

I wish they wouldn't do that. Nano is not Pico.

Vim isn't vi, but vi is usually symlinked to vim. And sh is very often a symlink to something like dash or bash.

can't you just... use nano?

Is it that weird editor they tend to put on our distro these days were we end up having a lot of i x r R :s/foo/bar :w and :q embedded in the text and that we need to close quickly in fear of adding syntax error before doing an EDITOR=vi ?

Who is "we"? You might be the only person out there who types out 7 full vim commands before opening your eyes to look at what app is running

That was tongue in cheek.

I would say the problem is not to not know which app you are using but muscular reflexes. Sames happen to me if I open gedit, notepad.exe or even an text processor such as writer or word.

I had to put vim binding to make vscode bareable otherwise I kept making errors.

Then `export EDITOR=vi` in your profile? Or in whichever global config file in /etc is appropriate, or possibly using your distro's alternatives system? This is an extremely solvable problem.

oh I didn't say it wasn't solvable, just that it catches me off guard every time I install a fresh new OS.

That's fair:) I would say that you should automate it by using ansible or something like that, but I've done that and there's still a very jarring few minutes while you're running the initial install and getting enough of a system for ansible to run on.

My first shared hosting provider used some BSD, I don't remember which. It was way back in the early 2000s. I could log in via ssh. But at home I used Gentoo and I couldn't deal with the remote shell at first. I had to press scroll lock to scroll up and down, found it out by accident. I asked the hoster how to edit files. He said Pico ctrl+o ctrl+x to save and exit. Pico then became my editor, because vi was even more alien. I believe everyone has searched for "how to quit vi" once :) . Anyhow, I wanted Pico at home and found that it didn't either exist for Linux or wasn't maintained anymore. And that there was this nano thing now. And to this day I use "nano -w" to edit files remotely and sometimes even locally.

I had a similar path to nano. Pico was the default editor for the Pine email client, and I still use Alpine for work decades later. I am generally an emacs user, but nano / pico definitely feel familiar and comfortable.

Same background for me and I'm quite literate with vi and emacs if/as needed, so now Alpine (email client) and nano are one-for-one replacements.

I wish back in the day people coming from windows were shown nano/pico instead of vi. If they had known there was something very analogous to dos edit I would think more windows people wouldn't have the experience with Unix they seem to have had.

Even today I am not a vim purist. I tell people to try nano out at first and work their way up to emacs or vim cause in the real world most people are just changing a line in etc that broke something.

I love Nano - it was the first terminal editor that I learned to use when Vi and other alternates seemed unnecessarily complex and felt masochistic (for someone who preferred a GUI for everything). (And on a hunch I just checked - Nano in macOS is still stuck at version 2.0.6!).

From a few comments above, you may be seeing pico instead of nano on latest Mac OS

[0] https://osxdaily.com/2022/03/27/get-nano-text-editor-mac/

No, I am on an older version of macOS and it is GNU Nano:

$ nano --version

GNU nano version 2.0.6 (compiled 19:02:51, Feb 22 2019) Email: nano@nano-editor.org Web: http://www.nano-editor.org/ Compiled options: --disable-nls --enable-color --enable-extra --enable-multibuffer --enable-nanorc --enable-utf8

(Anyway, upgraded to the latest version from MacPorts - https://ports.macports.org/port/nano/ ).

Nano is great, when I did not know how to use vi, vim or emacs I used nano. Nowdays for quick edits in terminal on unexplored servers I use vi. emacs and vim are not always installed

tldr: Main focus this release is on performance/optimization.

Multiline regexes, and colorization improvements (including NO_COLOR env var to disable). Support added for xsel (although it seems like most distros aren't using x anymore but better late than never!).

The fact is not that it now supports "xsel", the fact is a bug was fixed that prevented its usage.

Since I was a little kid my nickname was Nano.

One day I found an editor named Nano and I've been using it since :)

Nano helped me edit config files on a Raspberry Pi when I was 15 - very grateful for it for those moment. I use vim for remote editing and notes now as I've gotten familiar and prefer it, but Nano absolutely has it's place.

In high school I'd have to wait a few hours in the library every evening to be picked up, so I set up an SSH server at home and had my laptop with me. I didn't know about GIT at that time, so I'd SSH into my home server and edit files on the fly with Nano.

I actually coded quite a bit, and built a basic social networking app fully in nano.

Looking back I have no idea how I did it. Anything less than an IDE with VIM-mode is a no-go for me these days.

I do an Ubuntu based PXE deployment to over 10k servers. I still put nano on there.

I was introduced to nano when I did a `crontab -e` for the first time, and it had an ASCII arrow pointing at nano, saying 'easiest'. I tried it and realized it was perfect for quickly editing a file and getting out. I use it when guiding people unfamiliar with the CLI and they seem more comfortable with its shortcuts, as opposed to vi.

My Ubuntu is a bit behind, is this the official PPA for nano, or good enough? https://launchpad.net/ubuntu/+source/nano

Interesting codenames, very cosmopolitan (if a bit cryptic). I can translate the Romanian ones:

v6.1: "Social networks are like a fridge"

v5.7: "All the others were plowing the fields"

Give me Vi or give me death!

JK - glad to see Nano is still being developed. It was my first editor on Linux before I could learn Vi/m.

> Give me Vi or give me death!

When I was doing my PhD back in the 90's, I was mostly using Windows 3.11 and writing in Fortran. My editor: Notepad. Seems incredible now. The big boys doing other research had Unix boxes, big expensive Silicon Graphics machines of various colours, I believe. One of the programmers explained to me that vi was an excellent editor, and how you used h,j,k,l to move around. I kinda rolled my eyes and thought he was mad.

A systems programmer also suggested that I used "make". I couldn't understand the point of that, as that was what batch files were for.

Roll on to the present day, and vim is my editor of choice. I did flirt with emacs at one point, but gave it up as too much configuration is involved. On vim, I do virtually no configuration. I have no plugins whatsoever, although I have set up a few custom bits and pieces in .vimrc. With just one file, it makes it very easy to bring up a new machine for me.

I've come to the conclusion that emacs and vim are very different philosophies. With emacs, it works the way you want. With vim, you work they way vim wants. So ditch your plugins, and use vim the way nature intended.

Before doing my PhD, I did a masters jointly split between two universities. I think you can tell a lot about universities by what computer systems they have. One university had a lot of Sun systems. The file servers were prone to the odd hiccup, mind. At the other university, it was mostly Windows systems. In order to program in Fortran, we had to log into the university's computer (it was some Unix system, although I don't know specifics) via telnet, or something. And use "ed". Boy, was there some bellyaching from the students over that one! I always preferred the university with the proper Unix workstations. The Windows ones always seemed a bit of a joke, without proper software like Maple (IIRC).

Apple was shipping nano 2.0.6—from 2007!—until the current mid-cycle release, macOS 12.3. Probably due to newer releases of nano being GPLv3, they quietly replaced it with pico, which unfortunately lacks the critical Go To Line (^-) function.

I recently switched from joe to nano on small remote boxes, because it's there.

I'm still having issues to move lines around. Cannot get rid of my 80ies habits of C-k b, C-k e

I like nano for quick edits , but I was always bemused that it only gained an undo feature around the mid 2010s despite existing for many years before that.

nano is the first thing I always install on a fresh install (If it is not already preinstalled)

Reply on news.ycombinator.com