No, I honestly can't imagine why you'd need a conference for a tool. Maybe I'm missing something and the construction industry is similarly excited about DrillConf or TruckConf.
Nano was my gateway editor when learning *nix in college. I tried vi only to have to close the window to exit. I think nano can continue to safely bring in converts from Windows and MacOS.
it will probably take 4+ days to become faster editing text with vim than nano, and then you likely won't look back. Come back to the guide with decreasing frequency to add more knowledge to your vim arsenal.
I don't understand the people who dislike nano as an editor for the *nix system. After spending in it for like 30 minutes - it becomes an indispensable tool for quickly touching up text files anywhere you go to! No matter where I SSH to (*nix systems) - I always had nano available.
Probably the elitist guys, the ones that have their identity defined by the editor they use, the language and framework and the Linux distro/DE/OS they use.
Many people just need a tool that does a simple job but does it well, like editing a ini file and adding a line or a word, nano is great for that. (we all know that type of guy that has to tell everyone all the time that he uses Arch and Rust would have fixed everything)
> like editing a ini file and adding a line or a word,
That's precisely the use case that has made me remove nano from every machine I administer since the 90s.
Unless you're really careful to always start nano as "nano -w", its hard word wrapping will introduce line breaks where many configuration file formats (including ini files) don't expect, and it will do so in lines other than the one you're modifying. It's less risky to simply set another editor as the default. (But if you're careful to always use "nano -w", it's a perfectly fine editor.)
I've never seen nano on any popular Linux distro hard-wrap long lines by default. Yes, it's controlled by a setting, and some people turn it on for some reason, but I just confirmed it's off by default (no need for any command-line flag) in both CentOS and Ubuntu. You might have been burned by a setting left behind by someone with a weird taste.
I learned to always, always use -w back around y2k, when my buddy taught me Gentoo. IIRC he had gotten his firewall config messed up at some point, or similar, due to forgetting that.
These days I'm still too scared of accidentally messing something up due to not passing -w, so I just do it. It's in my muscle memory after all so doesn't take much effort.
I pretty much agree and share the love for Nano, but - just as a comment - it happened to me that it wasn't available in some Red Hat servers. Depending on your regular work and the type of servers you SSH into, you could expect Nano to be already installed or not
That's actually the entire reason I learned enough vim to be dangerous, on EL7 and below they did not ship nano in the box and there was a project I was working on where we had a bunch of 5.5 systems that had busted network configs. That was a.. joy, to say the least.
> No matter where I SSH to (*nix systems)
Nano is also available on Windows!
I have it installed through Scoop and I use it when I SSH to my Windows PC from Termux on Android
I've installed nano on every Linux system I've ever worked on, if it wasn't already there of course. For me, it's so much easier to work with than vim, for changing config files etc.
I only wish line numbers were enabled by default, or at least there was a simple and easily discoverable way to enable them.
Emacs has had TRAMP[1] (transparently allows you to edit remote files in your local editor using an SSH client) for literally decades now, while SSHFS has been around for nearly as long, and even zeitgeist tools like Visual Studio Code have equivalent TRAMP-like/auto-SSH addons.
The "it's not available on remote machines" line of reasoning hasn't been valid for at least 20 years (age of TRAMP), except for the case where you cannot SSH and have to physically sit at different consoles.
I love Emacs. I love Tramp. I love iTerm + Fish Shell more than eterm, though, so if I'm SSHing into a server it's from a terminal app outside of Emacs. In that situation, I'd rather use vim to make a quick tweak on a file than bounce to Emacs, tramp into the same machine I'm already in, and edit it that way.
Nano has/had some surprising defaults. Way back when, I was using nano to edit some file or another in /etc. When I wrote it out, it "helpfully" justified all the lines by inserting newlines to make them fit in 80 columns. My mentor looked at me disapprovingly, uninstalled nano, pointed me at `man vim`, and said "you're using this now. Thank me later."
Thank you, mentor.
I don't know if nano still has that as a default on any system that's shipped in the last 20 years, but I always give it the side-eye whenever a system has `EDITOR=nano` set and I run something like `visudo`. Am I about to break the entire system? Probably not, but to be sure I exit nano, configure `EDITOR=vim`, and try again. I know vim won't trick me like that.
Nano is now the default editor on Fedora since v33.
It makes sense. Modal editors have steep learning curves and were designed for an era of non-GUI interfaces running over teletypes. Everyone today knows how to use arrow keys to move around. Being dumped into vi, how many people will know how to go into the various modes to navigate and edit things?
I run OpenWRT on my router, nano is one of the first packages I install on it.
Switching to vim because you don't want to press ^L (or set the respective configuration option in .nanorc) to toggle off hardwrapping is a bit overkill though ...
It's not like "out of the box" vim is different in this regard. Half the time spent by a typical vim user with vim is coming up with personalised configurations.
Surely if I said I'm ditching vim for nano because I wanted columns hardwrapped at 80 characters by default you'd look at me funny, right? xD
It was more along the lines of "look, you've outgrown this tool, and it's time for you to move onto something more appropriate to the work you're doing". I'm not going to criticize anyone for using nano to edit the random file here or there (so long as using it doesn't break the file). But honestly, you reach the limits of nano's abilities fairly quickly. As fine as it is for a quick change to a file, Vim and Emacs other programming editors are popular for a reason. I surely wouldn't want to use it to work on large projects with lots of files.
I had a co-worker, whom I miss every time Nano comes up. He strongly preferred Nano, but not in an annoying way. He’d go through all our documentation and change ‘vi’ to ‘nano’, just because he could. He reasoned that anyone could use Nano if required, but vi could get a little weird at times.
I never understood the hate Nano gets from vi users. Nano does many things quicker and easier than vi. For example, search & replace. Would I code in Nano? No. Do I use Nano to edit configuration files and make other small edits? Absolutely.
That's pretty dismissive. I used nano early on and moved to vim and loved it. I think other people might have a similar experience as me so I encourage them to try vim or emacs if they're up for it. I'm not trying to justify my time in vim, I'm trying to encourage people to see if they might appreciate the tool as much as I do.
Not really, I don't configure vim and all my skills w.r.t. vim are via vimtutor.
Cost of learning: 1 hour (when I was bored on a long train ride and didn't have access to internet). I did the tutorial 3 times.
The basics of vim are easy to learn. Caveat: I do remember I had like 5 false starts in learning vim (and remembering nothing). This was before I knew vimtutor and googled for random tutorials. IMO, a lot of vim tutorials make out the vim basics to be much more complicated than they are. Vimtutor doesn't, vimtutor is the perfect example of a magic bullet.
Linus Torvalds recently did an interview and I was suprised to read that he was considering switching from his micro-emacs setup to Nano. If it's Linus approved, how can I say something is bad? ;)
Did you read the whole interview? He repeats the same statements, well basically because he was Asker the same stuff as always. Now his statements are zen level pragmatic. He doesn't want to get into a new editor that gets in his way.
I admit it is kind of underwhelming to read his answers. I am always hoping for some tidbits where he can state that he has seen the way. But for the most part it just pure hard work and true expertise of the systems programming domain. I guess the thing is evidence that true innovation often is rigorous and dry engineering.
So, nano, why not.
I for one use jed. I also finally learnt how to exit vim.
> I admit it is kind of underwhelming to read his answers. I am always hoping for some tidbits where he can state that he has seen the way. But for the most part it just pure hard work and true expertise of the systems programming domain. I guess the thing is evidence that true innovation often is rigorous and dry engineering.
Maybe it's because my day job is web development working with overly hyped up hipster front end developers (I'm a backend dev myself) - but I found his rather plain answers with no "eureka" in it to be quit refreshing. Linus is one of my heroes specifically because the primary focus in kernel development must be intense focus on fundamentals. I got into programming because of people like Linus so it's refreshing (to me) to here that being "boring" is just fine and even if you are boring you can still be a titan of industry by just being _that damn good_.
Don't mean to hate on Nano, but after all these years gaining inordinate vim muscle memory, an unexpected `VISUAL=/usr/bin/nano` default feels to me like a vim prompt must feel to a newbie.
I'm genuinely interested what you mean by this. What kind of navigating functions do you miss from vim when in nano? I'm almost 99% sure that they already exist (and if not, are perfectly scriptable to make).
IMO both vim and nano are perfectly fine tools. IMO the emotional gripes that people have with them are really more preferences in a world where everything is already near perfect.
Or maybe that's just me. Nano, vim, it's all good, but for the past 3 years I strongly prefer vim :P (before that I prefered nano because I couldn't find a good vim tutorial)
>Nano does many things quicker and easier than vi. For example, search & replace.
There may be instances where Nano does something quicker but search and replace would seem to be a perfect example of the opposite where Nano has taken a quick one line thing in vi and turned it into a multistep process for simplicity.
Exactly. And that can be extremely useful for people who either don't want to or can't memorize the vi one-liner.
Nano is different from vi because it targets a different set of users. Many of them use the terminal infrequently, so you can't assume they'll ever build up the kind of muscle memory that makes vi so efficient. You can't even assume that they'll remember any commands, so the commands are displayed prominently at the bottom. There's a reason so many Ubuntu tutorials for beginners use nano instead of vi.
The problem is that every time vim is mentioned, there are dozens of comments about how nano is a better alternative, which is completely missing the point. Most vim users are using it all day as their main editor for various purposes, and most nano users are using it as a quick tool for small edits. They're largely incomparable.
I'm intrigued. How do you search and replace in nano and how can it be better than `:%s/<regex>/<replacement>/gc`? I thought search and replacement was one of the killer features of vim.
In nano the equivalent command (as keystrokes) would be:
'^\' (or 'M-R') to enter 'replace' mode
<search term> (M-R to toggle 'regex' mode on off)
<replacement>
'A' to 'replace all' (or you can replace interactively)
And if you really want to shave off the extra 2 keystrokes for the 'M-R' toggle and 'A' option, you can always create a new macro in your config file that does just that.
> I never understood the hate Nano gets from vi users.
The reason I hate nano was that it's been forced upon me for in my view entirely misguided attempt to make the commandline more approachable. So that now instead of any competent unix person needing to have at least minimal skills with two arcane (but powerful) editors (vi - for editing, and emacs for shell keybindings at least), you now also need minimal skills with an essentially equally arcane but not at all powerful or, useful editor (once you have basic competence with either emacs or vi at least).
Wouldn't it have been much better to have provided a friendlier vi(m) config by default, given that this was already the default editor on any unix system before nano came along and there is actually some fair amount of benefit in learning it, because it's a powerful and widely supported set of keybindings (emacs and every major IDE have good vim emulation these days)?
Who is forcing nano on you? Why do they get to tell you what text editor to use? Blink twice if someone is holding you hostage at your computer, no one deserves a life of nano use.
Both the GuixSD and NixOS default system packages have nano and not vi. If you realize that you want vi, then you have to get it networked and change the configuration, all using nano, in order to install it.
If you have an IT career and ever advance far enough in it, chances are pretty good that you will eventually need to log into various types of servers, vms, container images that you either have no administrative control over or where this administrative control is not best used to switch around standard editor choices to suit your personal convenience.
Learning from this HN thread that apparently Nano gets hate. I've been programming for years, nano is still my go-to for "I'm in the terminal and I need to make a small modification". I use it daily.
Same here. I think it's better for small modifications. I find CTRL+o CTRL+x faster than ESC + :x, also there is no need to enter an edit mode. But at the end of the day is a matter of taste.
If you asked me, given no prior knowledge of any editor, whether I'd want to be dropped in nano or vim to make some random modifications somewhere it would be nano hands down. It's significantly easier to use and significantly more discoverable with the menu.
On the other hand vim is borderline a programming language for text.
It's kind of a slog at first. It's climbing a cliff to learn the basics, and that that point it's barely more productive than any other editor. Or maybe still less productive because a lot of simple operations are things you end up still having to go to Google for and spend some time reading through documentation.
But there's some point where you kind of get up that cliff and over the top of the mountain and it all sort of comes together on the downslope. Things start to become a bit more intuitive and become _easy_. You start to see the ways that a bunch of the little atomic bits you've learned can be chained together to create complex operations.
At that's the point where vim really shines. Once you hit that point it's kinda tough going back to anything else because it feels like working with one hand tied behind your back.
And that's all available... everywhere. Gui, terminal, local, remote, there's really no setup required beyond a `apt-get install vim` or `pkg install vim-console`.
But yeah, no hate on nano any more than I'd hate screwdrivers because drills exist. They're totally different tools.
nano is great as a quick command line config editor. I wouldn't use it for a big task, but it's wonderful to just dive into, make a quick change, and get on with whatever you were doing.
Has syntax highlighting support too, so you can have your config file nicely highlighted to make editing easier :)
There's nothing wrong with vi/vim or emacs either, but nano has got to be the most accessible command line editor out there.
Nano, it's been so long since the last time I have used it. I have so many fond memories of opening it to edit configuration fileson bare TTYs while installing Gentoo or Archlinux in the mid '00s. A few years later I switched to (N)Vi(m) (with quite a long Emacs parenthesis), but `nano` still has a special place in my heart as my first real experience with a CLI editor (if you exclude MSDOS' EDIT, of course).
As a vim and emacs user, I don't give nano any hate.
I'm surprised when programmers use it, sure, but that's because if my profession was going to require editing text files for hours a day (which it does), I would be happy to trade a steeper learning curve now for a less unpleasant job experience later.
I totally understand why non-programmers don't use it. If your job does not involve you editing text files for hours a day, then nano (or a graphical editor - gedit, kedit, notepad?) is inarguably a better choice for you than emacs or vim - the effort involved will probably never pay off.
ed users: you have my respect, which I will dispense from a distance.
I got a local login on a machine so busted that I couldn't mount /usr, meaning I couldn't read /usr/share/terminfo, meaning no screen editors would work. I knew just enough ed that I was able to fix /etc/fstab and bring the system up.
I wouldn't wanna use it every day, but it has its time and place.
Honestly at that point, unless your fstab is really big, I'd just `cat /etc/fstab` and then `cat >/etc/fstab <<EOF` and very carefully retype it (I mean take a backup first of course).
I used to use ed when all I had was a single terminal screen/window and a compiler error message. Ed doesn't clear the screen, so you can still see the message. Vi or emacs would clear the error message away. Of course, in a multi-window situation, the compiler output is usually in one window or pane and the editor in another, so this is moot now.
This is what i used to edit configurations in plan9 console if you don't have graphics support(over serial console) or to fix issues before starting rio. It is surprisingly pretty decent experience.
Its more like using the right tool for what you actually want to do.
0. Use cat and output to a file to really quickly make a new file from your clipboard or from the web
1. Nano is great for editing config / text files quickly and the learning curve is really low due to a more modern design.
2. vim can be reliably found everywhere on nearly any unix machine but the learning curve is much higher initial learning curve vim has more customization than vi and has basically replaced vi on modern installations of unix
3. emacs has out of the box has a learning curve less than vi but can't be found everywhere and you probably have to install it but it also has a large amount of extendability. the initial learning curve is a bit low but then it gets higher and higher. It also has multiple versions and a GUI and a package manager.
> Nano is great for editing config / text files quickly
emacsclient makes it just as easy to edit a text file extremely quickly with Emacs as to open a new vim or nano in place.
> emacs [...] initial learning curve is a bit low but then it gets higher and higher
Emacs's difficulty is, for simple editing cases that you could use nano for, only a little bit more difficult than nano, and certainly easier than vim - no modal editing, and you can learn the essential shortcuts (save, undo, open, close) in very little time.
I don't agree that the learning curve increases - more complex things require that you learn more about Emacs, sure, but my experience has been that it's about as easy to go from beginner to intermediate Vim knowledge as it is in Emacs, if not slightly easier due to the latter's better design and documentation.
As someone who has invested time into vim, I can edit text files with it much quicker than I could with nano. I also suspect someone with sufficient nano experience may be as capable of coding in nano as I am in vim.
"Use the right tool for the job" is all well and good (I mean, who wants to use the _wrong_ tool for a job?) but can lead to false dichotomies around tools which are designed to solve the same fundamental problems/use cases. I would posit that the model you suggest only is applicable to people with limited experience with vim, nano (and/or emacs). I would generally recommend that someone picks one and runs with it.
More than that, Benno Schulenberg, nano's main developer, is actively against changes turn nano into anything close to a mini-IDE. He rejected patches that could nano have code completion from external tools, multi-pane/screens, source code navigation and many others.
I respect his lead, but that discourages contribution.
I wouldn’t say it does so across the board. Rather, it filters contributions to only encourage those of the kind they desire.
There’s also the question of whether they even want “more contribution”. The less features, the less maintenance burden… Less maintenance burden, easier for fewer people to accomplish the work… Fewer people means less coordinating effort.
Simplicity seems to lead to a virtuous cycle here.
Same - I use nano for quick edits on remote boxes or locally but for programming I use intellij.
I totally get why people use vim (and emacs) in fact I use vim for one specific thing I can not do in intellij (highlight closing parens in docblocks - intellij doesn't do it and if you are writing annotations it's a major pita that it doesnt).
Same here. I like nano because it's a simple and intuitive editor that doesn't do much (though it does have some surprisingly powerful features once you know the shortcuts). I already have a full-blown IDE running on another screen and I don't want to spend any energy trying to stay on top of another one.
In other words, I would not use nano as my primary editor, but it's perfect as a secondary. If I need to edit more than a few lines, I'll just load up the file on my usual IDE.
One thing I've found nano useful for: git commit messages.
If the commit file is empty, that cancels the commit. Nano will tell me how many lines it actually wrote, so if I have second thoughts I can cancel with certainty. Nano may well not be unique in that regard, but I tripped over another editor that saved what I thought was an empty file as a single line with just the EOL character.
You can have a bunch of comments and empty lines, even with spaces, and git will still abort if you don't have anything else in the commit message. An EOL/newline character shouldn't cause the commit to continue.
There are overrides to make empty messages or including otherwise-comments, but yeah... you have to do such things rather explicitly. No way you can do it by accident.
I like to quit vim with a non-zero return value in some exceptional cases. git and most other tools will interpret this as "something bad happened" and won't do anything further
Upvote for mentioning WordStar. I only used it some in the Texas A&M computer lab. I went from my dad's Apple II, to a Commodore 64 I bought in college, to a Macintosh after I graduated. None of them were WordStar platforms, but I remember it was very popular in the CP/M and MS-DOS world before WordPerfect took over.
Yeah, for quick edits I prefer nano. Might just be because I grew up with edit on DOS, and Out of the vi, emacs and nano it was the closest and I just stuck with it.
Any programming I do is in Jetbrain IDEs.
But I saw a comment here long ago that says it's worth learning vim keybinds, even if you never use vim. Because you can be sure, no matter what IDE or editor you end up using, someone has created a vim keybinds plugin. You can have the same keybinds across everything.
Meh, that vim keybinds thing is an exaggeration. Using arrows keys for moving the cursor, holding down Ctrl for jumping words, holding down Shift for selection, etc is even more consistent across editors, and doesn't even need any plugins.
I was more thinking of the benefits of vim-style, the advanced controls for moving and jumping around according to code structure. Not just jumping a word at a time, but jumping to a character, deleting a word, sentence, block, etc.
Deleting a word - Ctrl-Delete. Deleting a line - Shift-Delete.
Jumping to a character, deleting a block - while vim does have bindings for these, I've never found myself using them. For the latter especially, moving to the start of the block and then selecting to the end of the block is better to me just because it lines up with my eyes scanning the thing I'm planning to delete. With vim I would have to pause and double-check what I'm about to delete anyway, and if it doesn't fit in one page I'd have to move around to inspect it anyway.
I've always been surprised by nano's ubiquity since it comes across to me as a very niche application. It's a highly-accessible, bare-bones text editor... for a terminal, where the overwhelming majority of users will be "power users" who will likely value the additional features made available by vim or emacs. It's not a bad tool. I just seems to be designed for a very small demographic.
Linus Torvalds said he might switch to nano for his daily driver[0]
>[Text editing is] all done in a traditional terminal, although I don't use 'vi'. I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar. I got used to it at the University of Helsinki when I was a wee lad, and I've not been able to wean myself from it, although I suspect I will have to soon enough. I hacked up (a very limited) utf-8 support for it a few years ago, but it's really showing its age, and showing all the signs of having been written in the 80's and the version I use was a fork that hasn't been maintained since the mid 90's.
> University of Helsinki used it because it worked on DOS, VAX/VMS and Unix, which is why I got introduced to it. And now my fingers are hardcoded for it. I really need to switch over to something that is actually maintained and does utf-8 properly. Probably 'nano'. But my hacked-up piece of historical garbage works just barely well enough that I've never been really forced to teach my old fingers new tricks.
I used joe for a while, basically because it was installed at the Uni's labs (and because I had used WordStar on DOS). vi (or vim, can't remeber) was misconfigured with terrible defaults, so basically I got used to joe.
It was very hard to force myself to stop using it and learn vi!
One of my colleagues is a old Unix hacker (one of my favourite things to do is get him ranting about his least favourite OS of all time, HP-UX 8.x). I have wondered before what editor he uses, and once when I peeked over his shoulder I saw that it was MicroEMACS. At the time I thought it might be a neat GNU Emacs clone with a smaller footprint, but no, it’s nothing of the kind. Old habits die hard.
I think your opinion simply reflects a degree of ignorance of nano's actual capabilities, rather than a genuine surprise at human behaviour. If anything, your comparison to gedit/notepad (notepad??? seriously???) makes that much clear.
Honestly I don't mind vim, but I prefer nano. And I spend 24/7 coding in my terminal. Nano covers all my needs and then some.
And while you should absolutely not switch vim to nano if you enjoy vim, I would totally encourage you to play around with nano a bit more. You may be positively surprised at what you find.
Just to be clear: are you coding in nano all the time in that 24/7 terminal session? But there is no syntax highlightning etc? To edit config files, sure. But most of the time spent?
I prefer nano too; trying to learn vim. But my coding happens in either Qt Creator or VS Code.
It's a quote from Harari's Sapiens book: "[History is something that very few people have been doing while] everyone else has been ploughing fields [and carrying water buckets]". For some reason, it's in Romanian.
It may sound full of hubris, but I don't think that's the intention. Check out https://www.nano-editor.org/news.php for previous release names. The maintainer has gone through a wide variety of references.
I learned Pico in college (part of our email system IIRC.) I don't code in terminal windows (prefer IDEs) and I can get by in vim. Inevitably I reach for nano when I'm editing config files.
I'm curious what the intended audience for micro is? It seems like if you want extensibility you use vi or emacs. If you want a very quick and dirty program where you use the same 4 or 5 commands every time you open it, you use nano since it's already installed. I don't know a lot of people in the middle, personally, so I'm curious what people who are using micro like about it in particular.
I used it when my laptop died and I decided to do continue working on my project using termux on my (low end) smartphone. It played well with the touchscreen and made a nice temporary environment. Basic and almost zero learning curve, but extensible and customizable when I wanted it.
Windows sys admin here. Micro is nice because it is a single-file, stand-alone executable that has mouse support, macro record/playback and syntax highlighting. (I haven't checked Nano recently).
Because of this, I don't mind installing it on servers. It is great for making quick edits to json configs, batch files, powershell, python scripts, etc. Syntax highlighting and line numbering are key. The alternative is editing the file locally and then getting it onto the server which can be challenging for locked down systems, especially Windows Server Core which does not have a GUI environment.
Even on my local machine, if I need to make a really quick edit, it is much faster to use this than waiting for VS Code or PyCharm to load. You also stay focused. By this I mean, your eyes don't leave the powershell window that you are currently working in. This allows me to more quickly complete the task at hand.
The key bindings for traditional text editors are awful. Micro uses the same normal key bindings that every GUI has used since 1984. A Unix should ship with an editor that has default key bindings that a normal user can guess how to use. Vi is an inexcusable choice for the default text editor although I understand why it’s popular for aficionados. It should be an advanced user choice, not a hazing rite of passage for newbs. Nano is close but still has the wrong bindings. Micro is actually correct. It’s not my actual daily text editor, but I use it when I just need a simple TUI editor.
I tried micro last time it was mentioned in a nano thread.
I really wanted to like it, and was actually excited to try it in principle, but in practice I tried hard to get into it for 3 days, and then got bored and reverted to nano.
Also, 'modern nano replacement' implies that nano is somehow antiquated. Not the case. (unless you're thinking of nano 2.9 which is what many linuxes unfortunately ship with by default instead of the latest shiny one ... no idea why).
It sounds the same to me as if you'd said that the pinephone is a modern Android replacement.
Even nano can become a powerful programming editor if combined with fzf[0]. You can quickly navigate to files, tags and language server stuff and then open your files directly into the line of interest. It's a nice exercise for someone willing to get a feel of the Unix way (I'm not advocating it as your daily driver, though).
I use nano when writing short Python or bash scripts in Termux for my Android phone. Is there a different editor I should try? Note that this isn't a common activity, so I'm likely to forget key bindings. I like how nano always displays those at the bottom.
Nano was a good alternative on Unix-likes in the old days for config files and such, since very few alternatives existed. However, CUA keybindings were a sore point. It could be almost configured to use them, but dragging config files around to every box was a chore.
About tenish years ago, I found "ne" and it was a bit better, but not a slam dunk.
A few years ago, I found "micro". It is what I always wanted, the simplicity of a CUA editor on Unix that I've used from DOS edit, to Notepad(++), to current GUI editors and IDEs, etc. I'd like a menu widget also, but that's a nitpick really.
Anyway, since it is packaged in Debian/Ubuntu now I've little use for nano. I no longer tolerate programs with unique keybindings, sane standards are a must.
I've always thought of nano as simplistic, but reading the discussion here, I see there is more to it than I thought.
I learned vi (precursor of vim) in the 1980s and the commands became second nature to me. However, as window-based systems and applications became the norm, I found it difficult to switch between vim and Windows or Mac applications, including the web. A good example of my problem involves the use of the escape key in vim to switch out of text entry mode, but many other apps use escape to cancel an action. I got tired of typing a paragraph, hitting escape, and then having to retype the paragraph because I had cancelled my input.
Nevertheless, it's great to have an editor I can easily invoke from the Linux command-line, so I still use vim for that. However, I will consider moving to nano for that purpose. At my age, I may never know it as well as the vi/vim I learned in my younger days, but it should still be useful.
156 comments
[ 21.0 ms ] story [ 3356 ms ] threadEverything i know about vi/vim is :q and :q!
it will probably take 4+ days to become faster editing text with vim than nano, and then you likely won't look back. Come back to the guide with decreasing frequency to add more knowledge to your vim arsenal.
Many people just need a tool that does a simple job but does it well, like editing a ini file and adding a line or a word, nano is great for that. (we all know that type of guy that has to tell everyone all the time that he uses Arch and Rust would have fixed everything)
That's precisely the use case that has made me remove nano from every machine I administer since the 90s.
Unless you're really careful to always start nano as "nano -w", its hard word wrapping will introduce line breaks where many configuration file formats (including ini files) don't expect, and it will do so in lines other than the one you're modifying. It's less risky to simply set another editor as the default. (But if you're careful to always use "nano -w", it's a perfectly fine editor.)
Also I've literally never encountered this behaviour even when copy-pasting code between two machines in my humble 10 years of using nano.
These days I'm still too scared of accidentally messing something up due to not passing -w, so I just do it. It's in my muscle memory after all so doesn't take much effort.
I only wish line numbers were enabled by default, or at least there was a simple and easily discoverable way to enable them.
Anyway, thanks - this looks easy to remember!
The "it's not available on remote machines" line of reasoning hasn't been valid for at least 20 years (age of TRAMP), except for the case where you cannot SSH and have to physically sit at different consoles.
[1] https://www.emacswiki.org/emacs/TrampMode
Thank you, mentor.
I don't know if nano still has that as a default on any system that's shipped in the last 20 years, but I always give it the side-eye whenever a system has `EDITOR=nano` set and I run something like `visudo`. Am I about to break the entire system? Probably not, but to be sure I exit nano, configure `EDITOR=vim`, and try again. I know vim won't trick me like that.
It makes sense. Modal editors have steep learning curves and were designed for an era of non-GUI interfaces running over teletypes. Everyone today knows how to use arrow keys to move around. Being dumped into vi, how many people will know how to go into the various modes to navigate and edit things?
I run OpenWRT on my router, nano is one of the first packages I install on it.
https://savannah.gnu.org/bugs/index.php?55067
It's not like "out of the box" vim is different in this regard. Half the time spent by a typical vim user with vim is coming up with personalised configurations.
Surely if I said I'm ditching vim for nano because I wanted columns hardwrapped at 80 characters by default you'd look at me funny, right? xD
They need to justify all the time they spent learning and configuring vi/vim to themselves and to others.
Cost of learning: 1 hour (when I was bored on a long train ride and didn't have access to internet). I did the tutorial 3 times.
The basics of vim are easy to learn. Caveat: I do remember I had like 5 false starts in learning vim (and remembering nothing). This was before I knew vimtutor and googled for random tutorials. IMO, a lot of vim tutorials make out the vim basics to be much more complicated than they are. Vimtutor doesn't, vimtutor is the perfect example of a magic bullet.
Just type vimtutor in the CLI and go.
I admit it is kind of underwhelming to read his answers. I am always hoping for some tidbits where he can state that he has seen the way. But for the most part it just pure hard work and true expertise of the systems programming domain. I guess the thing is evidence that true innovation often is rigorous and dry engineering.
So, nano, why not. I for one use jed. I also finally learnt how to exit vim.
Maybe it's because my day job is web development working with overly hyped up hipster front end developers (I'm a backend dev myself) - but I found his rather plain answers with no "eureka" in it to be quit refreshing. Linus is one of my heroes specifically because the primary focus in kernel development must be intense focus on fundamentals. I got into programming because of people like Linus so it's refreshing (to me) to here that being "boring" is just fine and even if you are boring you can still be a titan of industry by just being _that damn good_.
For what Nano is mostly used for, Nano has won.
Back in the day when vim would open it felt more as if my whole computer broke and nothing in the universe made sense anymore.
Nowadays with nano, I simply feel and think: ugghhh soo SLOW!
I wonder how other people experience it :P
Maybe someone could add vim binding support...
Or maybe that's just me. Nano, vim, it's all good, but for the past 3 years I strongly prefer vim :P (before that I prefered nano because I couldn't find a good vim tutorial)
There may be instances where Nano does something quicker but search and replace would seem to be a perfect example of the opposite where Nano has taken a quick one line thing in vi and turned it into a multistep process for simplicity.
Nano is different from vi because it targets a different set of users. Many of them use the terminal infrequently, so you can't assume they'll ever build up the kind of muscle memory that makes vi so efficient. You can't even assume that they'll remember any commands, so the commands are displayed prominently at the bottom. There's a reason so many Ubuntu tutorials for beginners use nano instead of vi.
And if you really want to shave off the extra 2 keystrokes for the 'M-R' toggle and 'A' option, you can always create a new macro in your config file that does just that.
The reason I hate nano was that it's been forced upon me for in my view entirely misguided attempt to make the commandline more approachable. So that now instead of any competent unix person needing to have at least minimal skills with two arcane (but powerful) editors (vi - for editing, and emacs for shell keybindings at least), you now also need minimal skills with an essentially equally arcane but not at all powerful or, useful editor (once you have basic competence with either emacs or vi at least).
Wouldn't it have been much better to have provided a friendlier vi(m) config by default, given that this was already the default editor on any unix system before nano came along and there is actually some fair amount of benefit in learning it, because it's a powerful and widely supported set of keybindings (emacs and every major IDE have good vim emulation these days)?
If you asked me, given no prior knowledge of any editor, whether I'd want to be dropped in nano or vim to make some random modifications somewhere it would be nano hands down. It's significantly easier to use and significantly more discoverable with the menu.
On the other hand vim is borderline a programming language for text.
It's kind of a slog at first. It's climbing a cliff to learn the basics, and that that point it's barely more productive than any other editor. Or maybe still less productive because a lot of simple operations are things you end up still having to go to Google for and spend some time reading through documentation.
But there's some point where you kind of get up that cliff and over the top of the mountain and it all sort of comes together on the downslope. Things start to become a bit more intuitive and become _easy_. You start to see the ways that a bunch of the little atomic bits you've learned can be chained together to create complex operations.
At that's the point where vim really shines. Once you hit that point it's kinda tough going back to anything else because it feels like working with one hand tied behind your back.
And that's all available... everywhere. Gui, terminal, local, remote, there's really no setup required beyond a `apt-get install vim` or `pkg install vim-console`.
But yeah, no hate on nano any more than I'd hate screwdrivers because drills exist. They're totally different tools.
Has syntax highlighting support too, so you can have your config file nicely highlighted to make editing easier :)
There's nothing wrong with vi/vim or emacs either, but nano has got to be the most accessible command line editor out there.
I'm surprised when programmers use it, sure, but that's because if my profession was going to require editing text files for hours a day (which it does), I would be happy to trade a steeper learning curve now for a less unpleasant job experience later.
I totally understand why non-programmers don't use it. If your job does not involve you editing text files for hours a day, then nano (or a graphical editor - gedit, kedit, notepad?) is inarguably a better choice for you than emacs or vim - the effort involved will probably never pay off.
ed users: you have my respect, which I will dispense from a distance.
[0] https://www.gnu.org/fun/jokes/ed-msg.html
I wouldn't wanna use it every day, but it has its time and place.
Everybody should know a little ed though, it's not that hard.
0. Use cat and output to a file to really quickly make a new file from your clipboard or from the web
1. Nano is great for editing config / text files quickly and the learning curve is really low due to a more modern design.
2. vim can be reliably found everywhere on nearly any unix machine but the learning curve is much higher initial learning curve vim has more customization than vi and has basically replaced vi on modern installations of unix
3. emacs has out of the box has a learning curve less than vi but can't be found everywhere and you probably have to install it but it also has a large amount of extendability. the initial learning curve is a bit low but then it gets higher and higher. It also has multiple versions and a GUI and a package manager.
nano is a clone of pico, the text editor for the pine email client, so "modern" is definitely a matter of some interpretation here. :)
emacsclient makes it just as easy to edit a text file extremely quickly with Emacs as to open a new vim or nano in place.
> emacs [...] initial learning curve is a bit low but then it gets higher and higher
Emacs's difficulty is, for simple editing cases that you could use nano for, only a little bit more difficult than nano, and certainly easier than vim - no modal editing, and you can learn the essential shortcuts (save, undo, open, close) in very little time.
I don't agree that the learning curve increases - more complex things require that you learn more about Emacs, sure, but my experience has been that it's about as easy to go from beginner to intermediate Vim knowledge as it is in Emacs, if not slightly easier due to the latter's better design and documentation.
> emacs [...] can't be found everywhere
TRAMP has been around for two decades now, making this largely irrelevant - https://news.ycombinator.com/item?id=26982916
"Use the right tool for the job" is all well and good (I mean, who wants to use the _wrong_ tool for a job?) but can lead to false dichotomies around tools which are designed to solve the same fundamental problems/use cases. I would posit that the model you suggest only is applicable to people with limited experience with vim, nano (and/or emacs). I would generally recommend that someone picks one and runs with it.
I respect his lead, but that discourages contribution.
Disclaimer: I'm a very sporadic nano contributor.
I wouldn’t say it does so across the board. Rather, it filters contributions to only encourage those of the kind they desire.
There’s also the question of whether they even want “more contribution”. The less features, the less maintenance burden… Less maintenance burden, easier for fewer people to accomplish the work… Fewer people means less coordinating effort.
Simplicity seems to lead to a virtuous cycle here.
It's decent enough for times when you want to do something quick on cli. And then spend rest of the time with graphical IDEs...
I totally get why people use vim (and emacs) in fact I use vim for one specific thing I can not do in intellij (highlight closing parens in docblocks - intellij doesn't do it and if you are writing annotations it's a major pita that it doesnt).
In other words, I would not use nano as my primary editor, but it's perfect as a secondary. If I need to edit more than a few lines, I'll just load up the file on my usual IDE.
If the commit file is empty, that cancels the commit. Nano will tell me how many lines it actually wrote, so if I have second thoughts I can cancel with certainty. Nano may well not be unique in that regard, but I tripped over another editor that saved what I thought was an empty file as a single line with just the EOL character.
But that's for small editing tasks. For coding I use VSCode or a JetBrains product.
Any programming I do is in Jetbrain IDEs.
But I saw a comment here long ago that says it's worth learning vim keybinds, even if you never use vim. Because you can be sure, no matter what IDE or editor you end up using, someone has created a vim keybinds plugin. You can have the same keybinds across everything.
I've never gotten around to learning though.
Those are not always standardized across editors.
Jumping to a character, deleting a block - while vim does have bindings for these, I've never found myself using them. For the latter especially, moving to the start of the block and then selecting to the end of the block is better to me just because it lines up with my eyes scanning the thing I'm planning to delete. With vim I would have to pause and double-check what I'm about to delete anyway, and if it doesn't fit in one page I'd have to move around to inspect it anyway.
>[Text editing is] all done in a traditional terminal, although I don't use 'vi'. I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar. I got used to it at the University of Helsinki when I was a wee lad, and I've not been able to wean myself from it, although I suspect I will have to soon enough. I hacked up (a very limited) utf-8 support for it a few years ago, but it's really showing its age, and showing all the signs of having been written in the 80's and the version I use was a fork that hasn't been maintained since the mid 90's.
> University of Helsinki used it because it worked on DOS, VAX/VMS and Unix, which is why I got introduced to it. And now my fingers are hardcoded for it. I really need to switch over to something that is actually maintained and does utf-8 properly. Probably 'nano'. But my hacked-up piece of historical garbage works just barely well enough that I've never been really forced to teach my old fingers new tricks.
[0] https://www.tag1consulting.com/blog/interview-linus-torvalds...
It was very hard to force myself to stop using it and learn vi!
Honestly I don't mind vim, but I prefer nano. And I spend 24/7 coding in my terminal. Nano covers all my needs and then some.
And while you should absolutely not switch vim to nano if you enjoy vim, I would totally encourage you to play around with nano a bit more. You may be positively surprised at what you find.
I prefer nano too; trying to learn vim. But my coding happens in either Qt Creator or VS Code.
These are the only terminal editors I really understand.
https://en.wikipedia.org/wiki/Pine_(email_client)
The name is a play on metric prefixes.
It may sound full of hubris, but I don't think that's the intention. Check out https://www.nano-editor.org/news.php for previous release names. The maintainer has gone through a wide variety of references.
- mouse select
- same keyboard shortcuts as vscode
other than that it's the same as nano
Because of this, I don't mind installing it on servers. It is great for making quick edits to json configs, batch files, powershell, python scripts, etc. Syntax highlighting and line numbering are key. The alternative is editing the file locally and then getting it onto the server which can be challenging for locked down systems, especially Windows Server Core which does not have a GUI environment.
Even on my local machine, if I need to make a really quick edit, it is much faster to use this than waiting for VS Code or PyCharm to load. You also stay focused. By this I mean, your eyes don't leave the powershell window that you are currently working in. This allows me to more quickly complete the task at hand.
I really wanted to like it, and was actually excited to try it in principle, but in practice I tried hard to get into it for 3 days, and then got bored and reverted to nano.
Also, 'modern nano replacement' implies that nano is somehow antiquated. Not the case. (unless you're thinking of nano 2.9 which is what many linuxes unfortunately ship with by default instead of the latest shiny one ... no idea why).
It sounds the same to me as if you'd said that the pinephone is a modern Android replacement.
Our goal is to ask others to edit some text files, not to ask them to use what tool to edit those files.
Cheers.
[0] https://github.com/junegunn/fzf
On topic (sic!): Hardcore vim-user, loving and recommending nano to every new Unix user. Guess I'm schizophrenic according to current HN comments.
I love the fact that it doesn't try to do anything more than edit text.
I'm happy to get in the middle of any vi vs emacs fight with the battle cry of "Nano for life!". The looks on their face is always priceless.
About tenish years ago, I found "ne" and it was a bit better, but not a slam dunk.
A few years ago, I found "micro". It is what I always wanted, the simplicity of a CUA editor on Unix that I've used from DOS edit, to Notepad(++), to current GUI editors and IDEs, etc. I'd like a menu widget also, but that's a nitpick really.
Anyway, since it is packaged in Debian/Ubuntu now I've little use for nano. I no longer tolerate programs with unique keybindings, sane standards are a must.
An Atonement of Nano - https://news.ycombinator.com/item?id=26063301 - Feb 2021 (100 comments)
Nano 5.0 - https://news.ycombinator.com/item?id=23995909 - July 2020 (195 comments)
Fedora Approves of Making Nano the Default Terminal Text Editor - https://news.ycombinator.com/item?id=23818199 - July 2020 (95 comments)
Fedora Devs Looking to Change Default Editor from Vi to Nano - https://news.ycombinator.com/item?id=21566828 - Nov 2019 (34 comments)
GNU Nano 4.0 - https://news.ycombinator.com/item?id=19476526 - March 2019 (147 comments)
GNU nano 3.0 released - https://news.ycombinator.com/item?id=17946145 - Sept 2018 (43 comments)
GNU nano 2.9.0 - https://news.ycombinator.com/item?id=15731079 - Nov 2017 (59 comments)
Nano to remain in GNU - https://news.ycombinator.com/item?id=12420683 - Sept 2016 (65 comments)
What’s up with nano? - https://news.ycombinator.com/item?id=11958728 - June 2016 (79 comments)
Nano is no longer a GNU project - https://news.ycombinator.com/item?id=11953044 - June 2016 (229 comments)
Check out:
https://www.nano-editor.org/dist/latest/cheatsheet.html
I learned vi (precursor of vim) in the 1980s and the commands became second nature to me. However, as window-based systems and applications became the norm, I found it difficult to switch between vim and Windows or Mac applications, including the web. A good example of my problem involves the use of the escape key in vim to switch out of text entry mode, but many other apps use escape to cancel an action. I got tired of typing a paragraph, hitting escape, and then having to retype the paragraph because I had cancelled my input.
Nevertheless, it's great to have an editor I can easily invoke from the Linux command-line, so I still use vim for that. However, I will consider moving to nano for that purpose. At my age, I may never know it as well as the vi/vim I learned in my younger days, but it should still be useful.