I used nano for years until I was forced to use vi when I was doing a FreeBSD install just for fun on my Cr-48. Once vim clicked for me I never went back. At the same time, Nano was invaluable as an easy to use terminal editor as a beginner. It was a huge help when I was learning to use Linux.
It's weird how comfortable familiarity is. I approached vim similarly, I first used pico/nano to modify files here and there but mostly used GUI IDEs or editors. Switched to vim and been using it for 10+ years.
Every once in awhile I encounter an OS where visudo or something else defaults to nano and I feel so awkward just trying to make simple changes and save the file.
The huge advantage of nano over vi in that scenario, is that nano 1) uses the conventional [i.e. as used by every editor other than vi] arrow key cursor movement and typing behavior without the need to toggle any modes etc, and 2) displays the shortcuts you need for anything else on the screen by default - things like saving, cutting/pasting, searching, and, oh yes, quitting.
So, while it might not be optimal for vi users, it is at least accessible to pretty much everyone regardless of their background. Whereas for someone not familiar to vi, getting thrown into the dreaded : prompt can be a frustrating nightmare.
Nano does what is does very well. Want to quickly modify some some file it is the tool of choice in the way a hammer is the tool to drive a nail. Right tool for the right job.
I dislike using nano because of this: open a narrow terminal and open a file with lines long enough to wrap. Insert a character on the wrapping line. nano will insert a line break, hard-wrapping the line. Probably you can customize this, but I don't want to have to customize an editor so it doesn't break my files.
Learning some basics of vi(m) and using some plugins to enhance it can improve your productivity compared to Nano on the long term (e.g. syntax highlighting with color palettes, linter, tmux support, and what not).
That said, I prefer Sublime/Vim (Sublime also has these plugins), but Nano is a decent alternative and resembles the first text editor I ever used. Sublime is lightning fast for me, but it isn't open source.
To break the habit of firing up Nano I symlinked it from /usr/local/bin/nano to /usr/bin/vim. If you use Vim regularly, the shortcuts will stick in your head whereas if you resort to Nano you won't memorise them for long. If I ever still require Nano then I can execute it by executing /usr/bin/nano
For people on a Mac, I can recommend the app CheatSheet [1] available in Homebrew. If you're lost in an application holding Command (⌘) for a few sec will represent you with a cheatsheet of shortcuts. It won't work with CLI apps though.
It depends on your experience, familiarity with the tools, and nature of the change. For example, you might think a single character change would be faster in nano, but that’s not necessarily the case. By the time you’ve moved the cursor using the cursor keys, deleted the old character, and typed the new one, an experienced vi user could well have made the same change faster.
We can all think of far more complicated changes that are considerable more efficient in vi. So the question is 'given perfect familiarity with the tools, and all else being equal, what kind of changes, if any, are more suitable for nano rather than vi.
None of that is to say that nano doesn’t have a place.
As a beginner it was my editor of choice, as most of us it seems. But the GUI made me want a better editor, with the same capabilities of a GUI editor.
So, when i heard of micro i switched immediately, I just find the default copy/cut/paste and the mouse functionalities very comfortable.
I love that there are people working on nano and the nano-styled website. Also excellent release notes. I just wish that nano in Bash for Windows was more recent than version 2.5.3 so I could try out the new features. ;-)
Some of my favorite memories are of learning C++ using the nano editor. I ended up a C# dev, put I still put nano on all my Windows boxes. It can be quite handy.
I think vi is probably more ubiquitous though, especially since it’s included in busybox which powers almost all imbedded Linux hosts. Still a good idea to learn a little vim
That's odd, considering vi is part of the POSIX specification and all. Many distributions won't come with full vim by default, but most do install a trimmed version of it to fulfil the role of vi.
I know how to get out of it, and also how to get into insert mode and make the most elementary of changes. I tried going further but it just doesn't mesh with whatever form of memory I have installed in my brain :-D
I helped my nephew (a teenager) with a coding project he was working on recently, and nano is what he was using when he made edits on the server. So, yes. People are still using it, and new people are picking it up because it's an easy editor that works anywhere. It seems like you'd want to learn something a little more powerful (like, say, vim) if you work on the command line via a remote connection frequently, but for every once in a while, you can't beat nano for ease of use. There's really no learning curve to do basic edits. (Meanwhile, some poor soul is struggling this very moment to figure out how to exit vim.)
I could use vi/vim, but I'm just too lazy to teach myself or use "vimtutor" to actually learn how to use it. I know just enough to open/modify/save/exit, which I think is just good enough for a quick edits.
It's a simple text editor that's available out of the box in most Unix-like distros these days. So kinda like vi, except I know how to use it (and if I ever forget, it lists all shortcuts on the bottom of the screen anyway).
I use it in a pinch fairly constantly. Despite being a heavily customized Emacs user all the rest of the time. Mostly when I'm already scouring around the shell poking at files or need to make a simple new one (like a .gitignore) and I don't want/need to perturb whatever else I'm doing in Emacs.
If you start Emacs server as a daemon, you can use it pretty much like you'd use nano/vi/vim in the terminal, without disturbing anything. With an Emacs server running, for me, it loads faster than vim. I have a bash function along the lines of
.. for using Emacs in the terminal a-la vim/nano. When you close the file you opened, you'll be right back where you left-off in the shell. I still tend to use a long-running GUI instance as you describe, but for jumping into config files from a terminal to edit a line or two, it's great.
This post makes me so glad to have been forced into vi all those years ago.
Its everywhere, its quick, and unless you've done some pretty nutty stuff in your configs, basic usage is the same between a heavily customized vi and the vi you find bundled with every is bundled windows and gentoo. (Not to disparage any preference for emacs; it just seems a bit much to have to fall back to an entirely different editor seems a bit much)
I don't _have_ to "fallback". I just choose not to interrupt the extremely rich development environment I have setup in Emacs and my projectile projects by bringing in random other files/buffers.
It's akin to the same justification for why I wouldn't bother opening a random tiny file in Xcode or IntelliJ IDEA.
I don't use Emacs as just a simple text editor. I can probably count the times I've typed `emacs some/file/path.whatever` into the shell on one hand.
First modify the buffer somehow. It really doesn't matter if you just type in "test"
Hit ^X to exit nano. When it asks you if you want to save the buffer hit Y
Save the file as "zzy" and press ENTER to trigger the Easter egg
^X+Y+zzy is likely a reference to xyzzy, a cheat code originally used in Colossal Cave Adventure[1]
1: https://en.wikipedia.org/wiki/Xyzzy_%28computing%29?wprov=sf...