Hacker News new | past | comments | ask | show | jobs | submit login
Nano 5.0 (gnu.org)
242 points by doener 15 days ago | hide | past | favorite | 195 comments

Thank you for you work on Nano! I'll never understand the elitism around text editors in the Linx world but am glad a user-friendly option like Nano exists.

Indeed. I kinda wish they would go the rest of the way and implement the standard keyboard commands that every other editor in the world (apart from vi/emacs) uses though.

Ctrl+c, ctrl+v, ctrl+x, ctrl+a, shift+arrow/home/end/pgup/pgdn/etc. etc to select text. It would completely eliminate the learning curve to edit text on linux, which seems like it could only be a good thing.

I actually think CUA binds are limiting and it's good to learn something else, but if you do want them, emacs has an option for enabling them. I've never tried it, but it's there.

Have a look at https://github.com/zyedidia/micro, which has those keybindings by default. Mouse support too. Completely eliminated the text editing learning curve for me, and years later, I still use it happily.

Edit: Oh, I see it's been recommended in this thread already.

vim works quite well with standard keyboards. Put this in your .vimrc:

set nocompatible

behave mswin

Or use `evim`.

Btw, 'set nocompatible' is never necessary in a vimrc file. When Vim detects a user vimrc file, it automatically sets nocompatible.

Control W is really annoying. But you can rebind keys, but that wasn't untill fairly recently that you could that.


I loved using Nano for a long time before I picked up Vim. I don’t get the elitism either, Nano is a great editor.

I like to think that the proliferation of different kind of editors reflects the incredible diversity that exists in what people want from an editor.

Nano is pretty solid. I think my muscle memory for using vi/vim instead has come from sometimes working on some really old nix systems that are air gapped from the world and therefore you work with what you have. I'm used to and use vim for everything at this point, but when dealing with new nix users that won't be working on crazy old stuff I always just steer them to nano.

Is the pico in your username a coincidence, or just particularly subtle and clever?

Nano's not really a programmer's editor. It's fine for writing short shell scripts and configuration files and you can't beat its ubiquity and user-friendliness but it lacks the tools and customizability most programmers prefer for production coding.

I'm a professional developer and I use Nano as my main text editor, entirely by choice. I've never missed the cool features that other editors like Vim and Emacs have, even though I've used both in the past.

I stopped warflaming but I really struggle on nano these days :)

weird right

A bit of a plug, but micro has been a nice alternative. Mouse support is enabled by default, ctrl+c/v works as expected, you only need to remember ctrl+e for other commands, as it opens a prompt where you can just type save/quit/etc.

Not in the repo though, which can be a no deal for many.

Oh right, it uses the operating system clipboard? That's kinda handy.

In other terminal editors I sometimes have to do a slight pause, to work out whether I'm using the editor-in-built yank chain, or pasting from operating system clipboard using the not-as-standard-as-Ctrl-V terminal emulator binding, Ctrl-Shift-V.

And then there's Vim which, depending on how it was built for the respective distro, doesn't seem to accept any way to copy or paste text.

As a daily Vim user I find this to be a huge mistake in terms of user friendliness; Vim provides ways to set the clipboard as default register and other quality of life improvements, but until then a beginner has to figure out some of the weirdest keybindings to make it work, or even recompile the program because that specific distro didn't include xclip support for some reason. It is infuriating.

I understand your practical frustration, but it can be very tricky with terminal apps to reliably interact with the X display. It's basically a completely foreign interface that requires the environment to be setup properly.

But in general I just install gvim (even if I only use Vim in the terminal) since it normally means that it'll have proper X support.

Middle click paste should "just work" and be transparent to terminal apps. It's not encouraging that vim is willing and able to break this in its default settings.

I could be misremembering but I believe that middle-click paste just makes the terminal feed the contents of the X selection to stdin of the running process. I could be wrong (because there's so much arcane knowledge in terminal emulators that I won't even pretend to have scratched the surface) but I'm not sure if Vi(m) can even tell where the input comes from. Well, maybe it could by using the speed at which the characters come in I suppose, although even that might end up being unreliable over remote connections and the like.

In my humble opinion expecting good X integration for a terminal application is bound to result in frustration. I use vim in the terminal but I also never use the mouse and I configure Vim not to interact with the X selection unless I specifically instruct it to using "*. If you want better integration with the graphical environment why not just use gvim? That's what it's for.

> middle-click paste just makes the terminal feed the contents of the X selection to stdin of the running process.

Recent versions of vim hijack this by default (`set mouse=a`). This makes the middle click paste the default vim register instead of the X selection. To paste from X, you must shift+click.

Personally, I can't understand why anyone would want this, but anyway. The best part is that you can't easily disable this globally, i.e. by putting `set mouse=` in /etc/vim/vimrc. Because if a given user does not have a ~/.vimrc of their own, then defaults.vim gets loaded after /etc/vim, overriding anything set there.

> And then there's Vim which, depending on how it was built for the respective distro, doesn't seem to accept any way to copy or paste text.

I install GVim, since it tends to be compiled with the most features enabled. You can still use the vim executable in a terminal and ignore the gvim one. Then it's just "+y / "+p to copy/paste, or add this to vimrc to map it to \y, \p:

noremap <Leader>y "+y

noremap <Leader>p "+p

I didn't know about the gvim "trick", that's good to know. Generally I just set the clipboard as default register so yanks and pastes work smoothly with other programs in every situation:

    set clipboard=unnamedplus

Try Ctrl+shift+c and Ctrl+shift+v

Unfortunately that does not work either in the worst case. I'm not quite familiar with the details behind all this, but I have had cases where it was basically impossible to get any text into or out of a Vim session aside from saving it in the text file.

I believe on Alpine OS I could get it working fine by installing some dependencies and recompiling Vim manually.

Others here have suggested to install the gvim package which seems to enable proper clipboard support in every case, I will try that next time I am in that situation again.

>on Alpine OS I could get it working fine by installing some dependencies and recompiling Vim manually maybe the mantainers of the vim package didn't use sensible build flags? vim copy-pasting usually works out-of-the-box on Debian/Ubuntu and Fedora, I avoid small and cutting-edge distributions exactly because of quirks like this

This works for me on Redhat, CentOS, and OpenSuse. I pretty much limit myself to these distributions. Work and Home Respectively.

I came to Mac relatively late and only after years of using Windows and Linux, but I really wish everyone else would copy Mac’s default English keyboard layout & shortcuts. Super+x/c/v for cut, copy, and paste, their relatively ergonomic combos for typing m-dash and various “special” characters using option/alt, and their screenshot shortcuts, especially.

>but I really wish everyone else would copy Mac’s default English keyboard layout & shortcuts. Super+x/c/v for cut, copy, and paste

Isn't this something that benefits mainly developers, at the expense of everyone else? Most people don't use the terminal, so they don't have any use for control-x/c/v. At the same time super-x/c/v is less ergonomic than control, at least for me. With control I can use my pinky + index finger, which is much more comfortable than using super, which requires me to awkardly use my thumb + index.

Admittedly it’s better on Mac keyboards, with Super directly next to the space bar. Less strain and movement to hit that with my left thumb than to stretch down to ctrl (if I hadn’t mapped caps lock to control). The rest of the layout is wildly better than any other I know of for composing text in English, which is a thing you’d think every default layout would be good at, but they’re not. Better than “standard” layouts on Linux and Windows, better than the “international” layout, and better than “alt-gr” layouts, at least.

[edit] every default layout for English, I mean. I wouldn’t expect a default layout for another language to be great for composing English text, obviously.

>Admittedly it’s better on Mac keyboards, with Super directly next to the space bar. Less strain and movement to hit that with my left thumb than to stretch down to ctrl

I'm not sure what you mean by "stretch down to ctrl". On a standard keyboard, with the control key in the bottom left corner, all you need to do is rotate your left hand slightly and use your pinky to press it. Doing so also puts your index finger in position to press the x/c/v keys. On a mac keyboard this is less doable because the control key is swapped with the fn key, but it also doesn't make pressing the command key any easier, as you still have to bend your left thumb to reach the command key (this is most apparent with c/v).

>The rest of the layout is wildly better than any other I know of for composing text in English

is this on non-US layouts? Looking at this https://store.storeimages.cdn-apple.com/4982/as-images.apple... or https://store.storeimages.cdn-apple.com/4982/as-images.apple..., the rest of the keyboard looks pretty close to standard ansi layout.

The cmd version with the modifier directly next to the spacebar involves no wrist rotation at all. I tried it to check before making my last post, and my hand feels way more tense doing ctrl+z/x/c than cmd+z/x/c, using a desktop PC keyboard for the former to make it fair. I can also move back into homerow position faster. If you’ve got super directly next to the spacebar, it’s both faster and causes less strain, as far as I can tell. Granted it’s a roughly neutral or very slightly worse change if super is between alt and ctrl.

Again, I did the standard Linux/windows thing for like 15 years before switching to Mac, so I don’t think I prefer it just due to familiarity.

[edit] the key to their layout being so good for writing is how Option/Alt is used. Option plus a character will often get you a common modified version of that character that’s very useful (so you can type, say, façade, or a —, quickly and easily). Holding option changes practically every key on the keyboard, and shift+option does it again to a different set of chars. They’re not perfectly discoverable and some are compose keys (but visible on the screen, not hidden as a key that seems to do nothing!), but if you forget where the cent sign or euro or or pound are it’s easy to remember they’re in the numbers somewhere near dollar and find them again in a second or two.

[edit edit] the international layout can be better for some people but is basically obsoleted by Mac’s “hold a key and see accented versions to choose from” functionality, and alt-gr is similar to what Mac’s standard English layout does, except worse.

What I really enjoy about micro is that it is one stand-alone static executable. It works well inside of a docker container just in case you need to edit a file in which the image did not ship with an editor (or volume is not mounted).

The Windows version also works very well.

Micro is great.

It is stable enough? I tried it a few years back, but it felt like a beta3 or beta4 software, crashing about once per day. But maybe things improved since then.

I've used it as my terminal editor for a few years and it's been good for me.

You should try it again. It is very stable now.

It is in Ubuntu 20.04.

micro > nano

Only if it is in the big repos.

Thanks to nano team for great work. It’s my favorite terminal editor for last 10 years. Too bad many systems has vi as default editor

Most liked features: kut lines, page up/down, easy search, syntax highlighting, editing long lines

When I was in high school and used my first Linux machine (a Raspberry Pi), Nano was always the recommended editor when I had to edit config files while not knowing what I was actually doing. Nano is great for those use cases for sure.

But as I've spent more and more time with Unix systems, Vim was become by go to choice. The customizability and power of Vim is great, but there is a steep learning curve if you've never used a Unix machine before and you're just trying to get WiFi working.

With that said, use what you like, all text editors do the same job in the end: edit text.

> When I was in high school and used my first Linux machine (a Raspberry Pi)...

Thanks for making me feel old! My first experience with editing text on a *nix system was vi on my older borther's AT&T SVR4 workstation in the 1980s when I was junior high (my apologies if that reference makes anyone else feel old!).

Actually you just made me feel really young! My first taste of Unix was a dialup shell account in the early 90's. IIRC, vi was the only editor available.

I'm jealous! My dad tells me stories of using Sun Workstations at his university back in the late 80s, and I get jealous of that being his first experience with vi! It's incredible that anyone can pick up a $35 computer now, but there is something so neat about those pre-internet Unix machines to me.

I wonder which editor the Nano devs use. It would make for an ironic anecdote if any used Vim or Emacs.

Not to say they couldn't edit their own source in their own editor, I'm sure it's quite up to the task. But I am curious to know.

I would imagine they use a full feature IDE, not a minimalist editor.

It’s like expecting the maintainers of notepad.exe to use notepad itself during development and not Visual Studio.

Gnu's flagship product has been Emacs since day one, so those folks using any flavor of vi would be sorta like Microsoft doing Windows development on Macs.

That said, it probably happens.

Nano has always been my go to editor. It comes natively with most install and is very easy to use. It has all the shortcut listed on page so it is quite user friendly out of the box.

After learning vim for a bit, I find nano quite superior for my use case mainly editing files inside terminal on remote servers.

Not only do I totally agree, but the words you used were almost verbatim what I was composing in my head while waiting for this page to load. It was a bit crazy to see my exact thought already as a comment.

But yeah, editors are just a preference, especially when every single one of them works in 90% of cases. I actually forked nano a long time ago (back in college) just to implement some niche multi-cursor hack because one guy said it was one thing vim could do that nano couldn't. I know there's plenty that <any editor> can do that <some other editor> can't, but nano's always Just Worked and occupied a very special, reliable, spot in my heart.

Nano is great. Too many linux installation or config editing guides recommend using vi, so I can see why that would put so many beginners off

As a huge fan of Vim, I begrudgingly admit you have a point.

To someone new to the command-line, Vim is not at all approachable. Once you know your way around Vim, it's a fantastic editor, and frankly Nano just doesn't compare, but you can't expect a newbie to be able to use Vim effectively. Without a tutorial and a deliberate effort to learn it, Vim is rather baffling.

To the question of what should be the default, I suppose it depends on the context. A power-user distro wouldn't have much use for Nano, the choice would be between Vim and Emacs.

My main problem with vim was, that I spent deliberate effort to learn some of its shortcuts, but I need to use text editor in a console only a few times per week, like change some config file or add line to cronjob. And then one tends to forget all the shortcuts, when not using it regularly enough.

Many IDEs and other editors have a vi-mode either built in or available as a plug in. I don’t use vim itself much (at work, at least) but I use vi keybindings everywhere.

Which are your favorites?

I have used the IdeaVim plugin for IntelliJ, and honestly it was so bad it was worse than not having the plugin at all. Maybe 20% of commands actually behaved consistently with vim. And IIRC, a decent chunk of my preferred vim functionality was outright unimplemented.

Perhaps ironically, I didn't have any such problems with the (commercial) plugin for Visual Studio. It worked very well. It cost $100, but my employer paid for that.

I've basically given up on IDEs after that and just use vim itself. If you know of any that have a really good vi-mode plugin, I'd love to try one!

Emacs has a pretty good vi mode called evil. I use spacemacs, but I am not sure, if it is what you are looking for. Should you try it, do yourself a favor and use the development branch. I read good things about doom Emacs as well.

Yes, I think it only makes sense to learn vim if you're going to spend a lot of time using it actively. I use vim for almost all programming I do, so that made it really easy to burn it in my brain forever.

When vi or vim opens for the first time, it should simply state 2 things:

- New to vi(m)? Close the editor by typing :q!

- Learn vi(m) by running the following program: vimtutor

Vim effectively does that with its splash screen:

                  VIM - Vi IMproved

                   version 8.2.814
               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

The problem is that a total noob will still be overwhelmed, Vim's UI is simply too different from modern UI conventions.

That's why I think it makes total sense for nano to be the default editor in this day and age, even it if means that I'll have to remember to set EDITOR properly if I want to use vi(m).

I think that's way too much information and agree that new users will feel overwhelmed.

This doesn't fix the problem. If it's a newbie, they should be given Nano. They probably just want to get the job done, whatever it may be. It shouldn't be assumed that now is the time for them to learn Vim (which is no small thing). Neither should it be assumed that quitting Vim solves the problem. They might not know how to reconfigure the default editor that some other program is using, for instance.

As long as I can remember, Gentoo manuals always assume you to use nano by default (although you can of course choose another). It's a distro that asks you to edit dozens of files in the installation process, and nano is definitely up to the job.

I guess they are being accommodative to people who don't know any editor to use, since those who have their favorite editor don't need to be told.

It's a matter of what you are used to. I'm used to VIM, so when I unexpectedly am dropped into Nano I'm a bit confused (never got around to using it much).

That being said, for new users without bias, nano definitely seems easier.

After about 14 years of considering Vim as my primary text editor and slowly attempting to forge a configuration that I was happy with, I recently resigned to the fact that I simply was never going to actually reach that point of having a configuration I'm happy with. I don't use Vim outside of the terminal; I spend most of my time in IntelliJ IDEA. I never found the Vim key bindings in IntelliJ IDEA close enough to the real thing to use, either.

So if I can't keep muscle memory of Vim keybindings, and I have never found a Vim configuration I've been happy with, why was I so stubbornly holding onto the idea that Vim was the right editor of choice for me? I don't know, but I finally changed my mind and looked for another editor. A dead simple one with sane defaults.

It came down to Nano vs Micro for me. Both are great. I ended up liking Micro a bit better, although I'm very glad to see that Nano development is still active.

Other than being a great editor, Vim has great value as a sort of practical joke you can play on people new to the command line.

"You can't figure out how to get out of the editor? I'm busy, stop asking me stupid questions. Look for the answer on Stack Overflow. Make sure to leave your mark there by up-voting the answer."

Yes, I hate people that can't read, too. Vim fucking tells you how to quit as soon as you hit ctrl^c. What the fuck m8. It's not even a funny joke anymore. It's just pure cringe.

On topic: It's weird that nano is so beloved, but good that GNU just keeps pushing out things as long as they are used.

Says this...

Type :qa! and press <Enter> to abandon all changes and exit Vim

Maybe not quite what the user was looking for. But I guess it does get you out of Vim.

ETA: Also, that answer on Stack Overflow at one time was the answer with the most traffic on the site. Reading must be a common problem for trapped Vim users.

I think abandon-changes is probably the best suggestion for most people in that situation. If you don't know how to exit you've probably made some accidental changes.

Vim tells you in the center of the screen how to quit when you start it up.

Only if you you're not opening an existing file.

> Nano has always been my go to editor. It comes natively with most install

While vi comes with all installs

> is very easy to use. It has all the shortcut listed on page so it is quite user friendly out of the box

Tell that to the users that don't know what ^ stands for

> After learning vim for a bit, I find nano quite superior for my use case mainly editing files inside terminal on remote servers.

I just don't understand how this is possible, except if you're doing very basic edits (even in that case...)

>Tell that to the users that don't know what ^ stands for

If you run `nano` it shows a message that you can get help using 'Ctrl-G'. In the second paragraph it tells you what '^' stands for. It will be a problem if you somehow ended in nano unintentionally. Even then someone can figure that it means either 'Alt' or 'Ctrl', that is the modifier keys.

>I just don't understand how this is possible, except if you're doing very basic edits (even in that case...)

Some people prefer or/and find easier to work with a modeless editor.

>I just don't understand how this is possible

I use nano as my daily driver, and here is how:

- I have a nanorc I copy around but am quite comfortable without. Here it is. You can use it under WTFPL-1. Feel free to fork it, but I'm not accepting pull requests.

  set multibuffer
  set nohelp
  # Defaults for older versions
  set nowrap
  set smooth
  set morespace
  unset boldtext
- I use ^K and ^U to cut and paste lines of text.

- If I need to edit multiple files, I use ^R

- If I need to find and/or replace, I use ^W (find), optionally with ^R (replace) and/or M-R (Regexp).

- Sometimes I need to go to a specific line/col, so I use ^_

Basically there's nothing else I want my text editor to do. I want minimal magic.

I know it's not the point you were answering too, but this is exactly why I don't think I will be comfortable in nano, ever. I already know vim, and I don't really bother to remember another set of shortcut just for nano.

When vi/vim aren't available, I usually just end up using sed.

The only thing you need to remember with Nano is that ^ means Ctrl. The rest you can find by reading the menus or the built-in help.

Which is why I prefer Nano over vim, I don't edit _that_ much from the console so I only have one easy thing to remember.

That's reasonable, but all the things a I listed are on the standard help bar, so the learning curve is minimal.

If there's no nano available like on busybox, I'll default to vi, but I don't prefer it.

At least in my case, I use nano typically for very simple edits, such as config files, fstab, etc. While I can use vim, I never “really” adopted it and get especially confused by the old “vi”.

As such, I almost always just grabs nano for these things, and use an IDE when working on code.

^ is quite obvious if you’ve tried to use any keyboard shortcuts in the terminal while a program is running.

Not really. Only after your comment i realized that it stands for any key at all. I never actually thought what it means before.

Yeah, for me when I was learning it was not-obvious, but wikipedia has an article on "Carat notation" I found by searching something like "what does carat mean in a terminal" on google.

Unfortunately, for me when I googled that exact phrase just now it gives a "Featured Snippet" saying it means "the beginning of a line", which is about regexen and and also only sort of right in that context. The wikipedia page is the first real result though.

Edit: I was spelling caret wrong. oops.

You mean "caret". "Carat" is something else: https://en.wikipedia.org/wiki/Carat_(mass)

I never had to Bing how to quit nano.

Ubuntu ships with nano by default? And every district Ubuntu I’ve used is defaulted to nano?

Ubuntu is nowhere near the only major distro. Maybe on the desktop, but most likely not on the server.

Edit: Also there are a lot of stories of "this old system that is central to our operation that nobody except that one guy 10 years ago knew how to set up" in companies.

I understand that Ubuntu may not be the /most/ popular distro. (tho everyone I know who runs Linux in AWS/GCE/Azure seems to run Ubuntu except me, I'm on Amazon Linux 2)

But the person I replied to said 'all' which is incorrect. If he said 'most' or something I wouldn't have replied :)

He said that vi is present in all distros, which is correct as far as I know. Not that it's the default.

I’ve been having trouble finding vi/vim lately on some installs, namely Ubuntu, although maybe they just leave it out of the default docker image? I use it sometimes for debugging conf files in between docker builds. But if you have to install something anyway, maybe it doesn’t make any difference if it’s vim or nano (emacs, though, I mean come on).

I think also I was on a real Linux box a few weeks ago (can’t remember what distro, sorry) that only came with ed by default. That was interesting, at least until I gave up and installed vi.

> except if you're doing very basic edits (even in that case...)

Most edits I do if I'm not on my daily driver is basic edits. Making adjustments to config files, etc. Doesn't require all the magic of Vim. Still prefer Vim though. Not having my Vim keybindings in an editor is like using a keyboard with a different layout.

Tell that to the users that don't know what ^ stands for

The users who have already figured out how to open a terminal, find their file, know what nano is and how to launch it?

Really wish all linux systems had it installed out of the box.

vi/vim is difficult for newbies. And the crowd that uses vi/vim will know how to install their editor of choice while the newbie doesn't necessarily

What systems don't come with nano these days?

CentOS/RHEL didn’t ship with it forever (at least to 7), I don’t know if that changed with 8 but it was one of the reasons I learned enough vi to be dangerous, as I had to debug a bunch of weird networking stuff on VM guests that were CentOS 5.5.

You might be happy to know that Fedora recently changed Nano to the default editor, which means it will likely land in RHEL as the default eventually.

I beleive Fedora 33 is defaulting to nano, so based on that so is RHEL

Some of the lighter distros designed for SBCs for example. Don't recall the exact one where I ran into this issue...openwrt I think

Not a disaster, but I don't personally have those arcane vi keyboard shortcuts memorized so even a small tweak to the config is unnecessarily painful

Yeah, openwrt doesn't have it, it only has busybox vi built in. Docker containers also often don't. But for most normal distributions it seems to be included these days.

>Docker containers also often don't

ah yes. That explains why my mind was so fuzzy & I couldn't place what specific distro I encountered this on.

It's not included with a default Void installation, either. It must be a charitable move to encourage greater use of Vim ;)

"nano -w" is a great editor. "nano" without -w should be banned like "rm -rf /" and require some long DWIM switch to even start.

Not wrapping should be the default for every editor. AFAICT, it is not the default for any editor.

I don't think nano is unique in this respect.

> Not wrapping should be the default for every editor. AFAICT, it is not the default for any editor.

It appears to be the default with emacs — at least, hard-wrap off appears to be the default. Soft-wrap is on, but … I can't imagine that you dislike soft-wrap, do you?

I do! It makes it difficult to see what's going to happen when I invoke operations on lines. And it encourages my colleagues to create long lines that would play better with diff tools like git diff if broken out.

Checked what came with osx

    >>> nano --version
    GNU nano version 2.0.6 (compiled 14:41:52, Apr 17 2020)
comfortingly my freshly brewed 5.0 looks identical when editing...


    >>> ls -l /usr/bin/pico
    lrwxr-xr-x root wheel 4 B Thu Jan 23 17:02:12 2020 pico ⇒ nano

aha! thanks

I started using Nano because of the Digital Ocean blogs. I still use it 4 years later, everywhere from side projects to firefighting in production. It's so simple and easy to use and I'm looking forward to 5.0 changes!

For config file editing, nano is great.

Vim's 'return me to the last location in this file'[0], however, is great when repeatedly editing large config files in this same place.

Nano should try to implement it, if it hasn't already.

[0] https://stackoverflow.com/questions/8854371/vim-how-to-resto...

That would be:

    ## Remember the cursor position in each file for the next editing session.
    set positionlog
The flag was there since 2011, but I only started to enable it a few months ago. Pretty nifty feature, although it took me some time to get used to the new flow.

Nano is my dog in the Vim-vs-Emacs holy war.

Nano is great as an idea - a editor with almost no features which is small, fast and is everywhere. Howerer, it suffers from the same as all open source projects. Working on it is fun, so they add new feautres with each version. Now 'nano' is not nano anymore. It even has had syntax highlighting for some time already.

I wasn't even aware that nano could be used as a "real" editor before I read these comments. I always thought it was like notepad.exe, meant for quick edits but not for any serious work.

I just discovered that it supports syntax highlighting, multiple buffer support, macros, a file browser and auto-indentation. It's only a matter of time before it gets Python scripting support. I'm sure its great if you like the editor but for something that's called "nano" it definitely reeks of feature creep, actually I just checked that the nano binary on my system is actually bigger than vi.

That being said when the most popular code editor these days is an Electron app, I suppose that "nano" is not technically false advertising.

> Now 'nano' is not nano anymore.

Nothing beats plain old 'vi' (NOT vim!).

Do distros still come with original vi? My understanding is that when you type 'vi' you get a minimal version of vim on most (all?) distros theses days.

'vi' is still 'vi' in OSX, and I believe the "original" 'vi' is accessible as 'nvi' on the usual Linux distros. (e.g., https://packages.ubuntu.com/focal/nvi)

nvi is new vi, released as part of 4.3BSD-net2. The only place I have encountered original vi is on Solaris. Solaris vi does horrible things like crashing if you maximize your xterm too big...

Can you highlight what differences make you choose vi over vim?

I think the comment is about vi scoring better on “lack of features” than vim, not about preferring vi over vim.

Of course, ed beats that, and the combination of cat and echo with redirection beats that (for a very limited definition of ‘editor’)

I wonder how many people here know about mc (as in midnight commander) and its builtin viewer/editor.

I love Midnight Commander. It's the first thing I install on any Linux system.

Whoa. A XTreePro clone!!

I do, but I much prefer nano.

I despise Nano. I support the effort of anyone working on open source, but really don't like using the editor personally. As a result, it's really frustrating when setting up a new box and VIM isn't the default.

> As a result, it's really frustrating when setting up a new box and VIM isn't the default.

However having Nano as default is the better choice. You as an expert know how to change the default. Newbies who don't likely will prefer a discoverable editor like Nano.

I agree. And if you only occasionally need text editor on a linux server, like when you change some config file or update cronjob and nothing more, nano is perfectly adequate, without needing to learn all the vim shortcuts.

> And if you only occasionally need text editor on a linux server, like when you change some config file or update cronjob and nothing more, nano is perfectly adequate

That's precisely when nano is the least adequate: "sudo -e" or "crontab -e" won't pass the "-w" flag to nano, and without that flag, the automatic hard line wrapping can easily corrupt config files which depend on line breaks for their semantics (a crontab being a great example, where each line is a separate entry).

Thanks, I check that flag. Anyway, I never encountered the problem you are mentioning...

That can go in nanorc

> However having Nano as default is the better choice. You as an expert know how to change the default.

Speak for yourself. It's not better for me and I had to do some googling to figure out how to change the default when it was changed to Nano. I'm not an "expert" in any sense, but I'm sure a lot more comfortable with VIM than Nano.

Also, I'm not sure most people setting up VMs newbies, at least in the way you're using the word. I have no problems with Nano being installed as the default on some distros. I just wish it weren't on the one I use!

Thank you for speaking for the rest of us.

What's nuts to me is how often I hear people complain that that can't figure out how to quit out of nano when those exact instructions are always visible at the bottom of the screen.

But you have to know that the "^" sign means "hold ctrl".

When you first open nano, it tells you at the bottom of the screen that you can press "Ctrl+G" for help. The second paragraph of the help text explains the '^' notation, and the help further explains that you could have accessed the help page by pressing F1, which has been a common key for accessing the help feature of whatever program you're using for decades.

These are people who prefer vim, and are perfectly fine with the :q magic.

Shift + zz

For me, nano was the text editor that I immediately knew how to use. No need to learn, you just read the bottom of the screen, and you can do the basics. For writing a commit message, it's more than enough.

Compare that to Vim: it's a great tool for coding, very powerful, you can easily customize it, optimize it to your needs, but you actually need to spend time learning to use it, and then tweaking it to your work.

I am the reverse, I hate when I ssh in a server and try to edit crontab and I get hit with vim. At least now vim shows you how to quit it if you attempt to ctrl+c it. I don't need vim when I want to edit a 10 line files.

> At least now vim shows you how to quit it if you attempt to ctrl+c it.

This has been the case for at least ten years. I started using Linux in 2009 and the first time I opened vim, I tried using ctrl-c to quit and saw that message.

Servers are usually running LTS Linux versions and I had to Google how to quit vim a few times because I forget. Same with closing a frozen SSH, I kinda know the shortcut but I am always wrong a bit so I eventually remember it or Google it again. Things I do not use often are just wiped from my memory.

My anecdotal evidence: when I'm working on a VPS or making changes in terminal on my non-windows devices I wouldn't know of any other editor that I could use that is not Nano.

Occasionally I've been taken to vi or vim and I wouldn't know how to cut/save the file. So I appreciate Nano for exposing those actionsore clearly.

Maybe the alternative would be to ask user what editor they want to use whenever they try to edit a file - yet suggest Nano as the default for those who have no experience on any other editor.

When I started using Linux, nano was often the default, and it had the tendency of corrupting configuration files because of its automatic hard line wrapping unless called as "nano -w". To prevent that kind of accidental corruption, I always remove nano from every system I administer.

Nano's never done that to me, and I regularly update a single-line authentication cookie in a config file. Do you remember which distro you were using? Sounds like it included a weird /etc/nanorc file.

Debian's has `set nowrap`.

> Do you remember which distro you were using? Sounds like it included a weird /etc/nanorc file.

It was a long time ago, back in the 90s; it probably was either Debian or Slackware or Conectiva.

Edit: it probably was Debian, I found contemporary bug reports complaining of that, for instance https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=127634 and according to https://metadata.ftp-master.debian.org/changelogs/main/n/nan... the default /etc/nanorc was changed to disable wrapping only many years later in 2.0.9-2; even then, you're still depending on nobody commenting that line on /etc/nanorc. Removing the whole package is much safer.

I was in a workshop organized by ElasticSearch. They provided to their VM from browsers. All Vi guys there got stuck because the keybinding didn't work on the browser.

I helped some guys there, shown them how to use nano. And then could move on with the ES demo.

I despise vim, not sure how they thought that such a design was reasonable for an editor (e.g. the fact that typing doesn't insert text at the cursor position unless you press Insert first).

Nano, on the other hand, works properly as an editor.

vim was designed to work like vi, which is older than the standard behavior you are talking about. What seems reasonable is basically just what you are used to.

Well, that behaviour makes it easier to move around in a file, which is exactly the point.

I have the opposite problem from Vim novices. I genuinely cannot exit from Nano.

Exactly. The real user friendly editor would always show you the "top" commands that can be accepted.

But some !@$ in some distros or programs set the defaults of nano to not show the "help lines." So I know it's Nano, but as I don't use it all the time I don't remember how to do anything but typing the text.

Not a good configuration.

And still, at least after the Esc was pressed it should show the help lines, and not pretend nothing's happened! That's a missing feature! Even decades ago the user friendly text based editors had that.

And the help is still talking about the "Meta" key -- when have you the last time seen the physical keyboard with the key labelled as "Meta"?

Same thing here ^^ It's annoying to reflex type `:q` and see it on the screen and nothing happen! One good thing with nano being beginner friendly is that it reminds you at all time how to quit on the bottom left of the screen so the annoyance doesn't last long.

"Ctrl+x", "y" or "n" if you need to save, then "Enter"

Wrong, you just hold down Ctrl and then randomly mash 'O', 'X' , and Enter until it kicks you back into the shell like a screaming infant

Thanks. Well, now I can't make that joke any more!

try micro. it's better than both

Swap nano and vim and that's how exactly I feel. :-)


Startup time: 1ms, vs 3000ms

What are you talking about?

$ time emacs -nw -q --eval '(save-buffers-kill-terminal)'

emacs -nw -q --eval '(save-buffers-kill-terminal)' 0.06s user 0.01s system 99% cpu 0.077 total

nano is the best.

It's the notepad of the linux world and like notepad I probably use it more than just about any other application than the browser.

But it's not standard. Ed is the standard editor.

It's the standard of how my brain operates.

and sed is the stream editor

Micro looks nice, but Nano just works when SSHing from Windows, Micro requires some X things to support copy and paste.

Yeah, micro seems quite nice. Bit of an uncanny valley, however, because as a terminal editor, it doesn't support emacs/zile keybindings, and by default it doesn't use nano keybindings.

However, I just realised that if I think of micro as a notepad alternative, the keybindings make total sense.


Funny way to spell vi

You can't compare vi and emacs, emacs is more comparable to nano.

emacs used to be my great enemy, until i met someone SO into emacs and elisp, in each of his dual monitor he had emacs opened. With the two instances sharing the cursor (unless it was one emacs opened in two windows, but i think this is way harder to code). He had no mouse and was surfing with emacs, reading/writing his mails from emacs, had a kanban on emacs... That force respect.

Now i tried evil mode and while i'm still using vim8, i might try to learn elisp during my sabbatic year.

You are asking for a flamewar

Obligatory xkcd: https://xkcd.com/378/

Dammit Emacs!

I was always been annoyed whenever an editor other than vi opened in a console/terminal. Recently I've been learning an alternative keyboard layout which has gone well--except that my vi muscle memory is completely broken. I think I'll appreciate this now and accept it gladly even when my new vi memories are formed.

Wow, those are useful improvements... especially the toolbar. A bit slow in arriving, but still good.

> For the color names red, green, blue, yellow, cyan, magenta, white, and black, the prefix 'light' gives a brighter color.

Catching up to the Nineteen...eighties, I think? :-P

Nano is the singularly greatest tool for Windows users to be productive administrating a Linux implementation. I love this editor and have been using it since it’s first release.

I am currently using vis editor[0] and I am liking it.

[0] https://github.com/martanne/vis

I've often thought about contributing to the nano project. Having written a few editors myself I still have a passion for it. I use nano for quite a bit.

If you are an emacs person but need something like nano for quick edits on remote machines, try "mg".

I think it's the default editor on some BSDs.

I don't do a ton of editing in a non-graphic environment but enjoy confusing the other C# coders at work by editing a code file in vim with ConEmu from time to time. I never thought to see if Nano was also in ConEmu until reading the linked announcement and these comments -- and it is! I'll have to play with Nano a bit more but it seems like the difference between editing in Notepad versus VS Code: good for really simple stuff but the power of vim is needed if you're doing something non-trivial.

Once, as a little personal challenge, I've used solely nano + fzf as my IDE and programming editor. I went pretty far with it :)

how far can you go? I've been on the lookout for a friendly vim like editor. at the same time I really like a IDE features

Interesting — I did not realise Nano was a GNU project again. In fact, Nano apparently did not leave GNU for very long.

For details: https://nano-editor.org/news.php

Leaves GNU in 2016 June 17, rejoins GNU in 2016 September 1

Some past HN insight (Misleading information in my HN thread? It's more likely than you think): https://news.ycombinator.com/item?id=11953044

Blog post by Chris: https://www.asty.org/whats-up-with-nano

"Request to move nano from gnu to nongnu" https://savannah.nongnu.org/support/?109076

"[Nano-devel] nano to remain in GNU" https://lists.gnu.org/archive/html/nano-devel/2016-08/msg000...

>For details: https://nano-editor.org/news.php

That's a beautiful website.

This editor is my daily driver. Has been for years and years. Glad it's still kicking!

mcedit is what use instead of nano. Similar to the editor in Far Manager and Norton Commander.

I'm bothered by the UI design of this webpage.

The first thing I uninstall on a new system is nano.

I don't uninstall it but I don't really get the love, mostly because of the keybindings. Maybe I'm too young and don't know its legacy but they seem super esoteric to me and I've never seen them anywhere else. Emacs navigation bindings are similar to terminal bindings, and well vi is its own world but at least fairly widespread today.

nano is a GPL-licensed clone of pico, which in turn was originally conceived as the integrated message editor in PINE, the popular UNIX e-mail client first released in 1989. If you look at the overall interface of PINE you will recognize that it is consistent with pico/nano, but other than that there really wasn't much consistency in terms of keyboard commands between apps in 1989.

More importantly, while for instance ^S for "save" might seem more natural than ^O for "writeOut", remember that dumb terminals over slow lines were still very much a thing in 1989 and ^S was already used as a terminal control code for XOFF (software flow control) -- which is why nano throws that "XOFF ignored, mumble mumble" message when it catches ^S.

+1 to uninstalling nano

I get stuck in nano like other people get stuck in vim. I definitely prefer vi as the default editor. But I understand that this does not apply to everyone.

It has a cheat sheet at the bottom, including how to exit, though? Like maybe there’s some way to disable it with a switch but I’ve never seen nano without it.

I know. The cheat sheet gets me out of it. But I think my problem is that the keys that I press intuitively are the wrong ones and it keeps asking me to press more keys to get out of it :-)

I don't uninstall it, it's good to have it around just in case. And removing a base system package _will_ break things.

But I always change the default editor to something more emacs-y:

    export EDITOR=/usr/bin/mg

Agreed. Investing the time to learn to use vi properly will pay off hugely in the long run.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact