Nano 5.7
lists.gnu.org
lists.gnu.org
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 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.
:cqBut 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.
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.
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.
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.
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
Everything 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.
- 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.
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.
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.
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)
On topic (sic!): Hardcore vim-user, loving and recommending nano to every new Unix user. Guess I'm schizophrenic according to current HN comments.
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.
Check out:
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.
Our goal is to ask others to edit some text files, not to ask them to use what tool to edit those files.
Cheers.
These are the only terminal editors I really understand.
I love the fact that it doesn't try to do anything more than edit text.
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.