I must have used nano for years at this point, and I'm shocked to find out how customisable nano actually is!
I tend to use micro[0] on most of my systems now just because it comes with really lovely defaults and keybindings that are a bit more familiar, but this might make me take a second look at nano in future.
It's not just customisable, it's also insanely scriptable. Any action that you can do in nano itself corresponds to a command, and you can create "string macros" that you can bind to key combinations. Additionally it can execute external commands on any nano buffer and return the result. Combining the two is very powerful.
E.g. I have a configuration which allows me to use nano while editing pdf side-by-side, and be able to click on the pdf and land in the correct line in nano, and vice-versa. (and obviously compiling the latex document itself happens via a custom keystroke).
Simple. I don't know emacs that well :)
I didn't even know emacs had a terminal mode until I looked this up; my main experience with emacs was when I was writing prolog and the IDE was emacs based. I didn't find it as nice to use back then so I never gave it a serious shot.
By comparison nano is everywhere and was super-simple to configure and spruce-up with custom functions, so it just stuck with me.
As for other competitors, when comparing to vim, I find it much simpler to use, and to the surprise of most vim users I speak to, equally powerful (at least for my needs).
Before I used micro & ne I used nano, and configured the keybindings to work in the CUA style. I still have the dot files, didn't delete them, but they rarely get used anymore.
I think they recently added Ctrl+S to save by default, even if unconfigured, woohoo.
Promising but very barebones. Hard to do without syntax highlighting these days, for example. But I think it would be useful on a tiny machine with openwrt, as micro is huge there. ;-)
Same same. Never even occurred to me to look. That's the risk of a (successful) low-friction product though: you use it in quick bursts where the tool is necessary but largely invisible, and you never invest in learning more about it because it works so well with the defaults. There's probably a profound strategic insight buried in there somewhere.
It seems few people are aware of how customizable nano actually is. Usually, they use nano with the default preset for quick bootstrapping tasks and then switch to vim without hesitation. While vim/neovim are certainly very powerful, nano remains my go-to editor for many quick terminal operations. I've customized it quite a bit[1], especially the key bindings, though the defaults are already excellent.
Nano is my go-to whenever doing something quick in the terminal. It's quick, I don't need to learn how to use it, and now it's going to be slightly more convenient. I had no idea it had these options. Thank you!
Nano is by far the best terminal editor imo. The only situation where I'm using a terminal editor is when I'm ssh'ed into a server, and I need to quick edit a file (for serious code writing a GUI editor is far more capable). Nano is ideal for that use case: you get in, it tells you what all the relevant keybinds are right on the screen, and you get out without any fuss.
Nano is quite a venerable piece of software with the initial implementation shipping as pico, the text editor for the pine mail client, back in 1992. Tens of thousands of students at a few universities will have been introduced to it as their very first email client.
The pine authors fell foul of the Debian free software guidelines and, as well as nano, a clone for the mail client itself lives on to this day as alpine. I use it every so often for a spot of nostalgia.
This is exactly my path to it, and even though I know how to “eat flaming death” vi and used emacs for awhile, nano is still my default “edit that config file quickly”.
Same. My first internet access was a BSD shell account back in 1993; I had Pine and Pico on there. Coming from a world of MS-DOS BBSes (I ran one myself!) it wasn't that hard to take QEdit skills and move that over to using Pine and Pico-- it was quite comfortable.
I still tend to muscle memory my way through using Nano when I need to do quick file edits on Linux.
It's also possible that you simply do NOT have nano installed at all, and just have the simlink from nano to pico by default. That was my case. In this situation, install nano and it should work.
Right after the nano maintainer got bullied out by the FSF, I noticed two bindings got their defaults changed. They never change. I almost feel like it was graffiti, a flex against the old maintainer, a retribution for not doing whatever the FSF wanted.
Since forever, GNU readline programs and nano had identical bindings. I'm fast moving around the CLI because I'm fast at nano. Emacs has the same defaults. What sane organization only abandons their own defaults and prioritizes that work after pushing the existing maintainer out (or irritating them enough to accomplish this)?
Seems GP got somewhere confused as well. From `man nano`:
Since version 8.0, to be newcomer friendly, ^F starts a forward
search, ^B starts a backward search, M-F searches the next occurrence
forward, and M-B searches the next occurrence backward. If you want
those keystrokes to do what they did before version 8.0, add the fol‐
lowing lines at the end of your nanorc file:
bind ^F forward main
bind ^B back main
bind M-F formatter main
bind M-B linter main
M-F/B have not defaulted to nextword/prevword, or at least haven't within the last 10y since have those binds in the earliest version of nanorc in my .config git repo.
The line numbers and position bar are some real quality-of-life enhancements!
I don't regularly use nano anymore, but I have often thought that more programs should imitate the way it shows the command shortcuts on-screen as a kind of instant tutorial. I remember my physics major friends in college thinking it was pure snobbery for vi not to do that by default. Back then we were dialing in to an HP-UX server and using pico, which nano is an open-source clone of. For those who aren't aware, pico was originally the editor component of the Pine email client.
> physics major friends in college thinking it was pure snobbery for vi
I don't think it is snobbery, that approach would clutter the entire screen. Basically every single small/capital letter and symbol has a function in vim.
That seems very likely. One of the first things I'd noticed back in the early 90s when I got my shell account and used Pico for the first time was that the UI was similar (not exact copy, mind you) of how Wordstar was, with some basic guidance at the bottom to get you started.
Also kind of reminds me of the old Telix terminal software for MS-DOS, with the bottom status bar. Not exactly the same, but again quite similar in the approach to have you just quick glance at the bottom of your screen for a HUD.
I actually prefer 'constantshow' instead of 'linenumbers'. That way if you want to select/copy some text from the terminal it doesn't include those line numbers.
My struggle is that I work on lots of systems, sometimes ephemeral/temporary systems. There is no easy way to "sync" customizations, so I adapt to defaults.
Even basic things like how shell history is managed is very annoying to configure every single time. if only it was as simple as cloning your private github repo to ~/.config.
I use a very customized emacs/evil setup, and before that a very customized vim/neovim setup, but I've never had trouble jumping onto systems where only plain Jane vi is available. I think it's because of the color scheme, or lack thereof, that I don't have any problem automatically switching. If I don't see my color scheme, by fingers just automatically use vi compatible bindings and I don't find myself expecting my other customizations to be present.
Maybe not everybody can switch so easily, but I think it's worth trying out. (One change that absolutely does trip me up is capslock->control. If I try using somebody else's computer, I constantly enable capslock by accident.)
Cloning a github repo to ~/.emacs.d is how you can cart around your Emacs config. I've been doing this for years, and it works nicely. For things configured by files that live in the home folder directly (e.g., shell - and looks like Nano would be similar?), I've got another repo with a couple of install scripts that create symlinks to the version-controlled files. I don't love the extra steps, but I've found this works pretty well too.
Most of the time, I can manage without, but every now and again I've needed to do some thing or other, and I've been grateful to have my own preferred setup rather than somebody else's.
I don't really sync my config. I just scp or wget files when I need them. I have some config as gists, as snippets in my notes, as public files in a webserver under a subdomain.
What would it take to have "vim-wiki" for nano (see also: FOAM, Obsidian)? I have always admired nano for how simple and easy to use it is, and would love to use it for wiki/obsidian-style note taking & linking...
Nano doesn't really support any sort of scripting or plugins beyond macro sequences AFAIK. So, not really in the same sense as something like vim-wiki etc. You might be able to cobble together something with shell scripts and text files, but it won't be well integrated.
Is it possible to apply some of the settings like autoindent or line numbers only when editing source code? In other words, does it have different modes like emacs?
Wouldn't that make vi(m) just about the worst tool to exist? There's a reason that the "how do I exit vim" jokes exist, it's because the UI is awful unless you already know how to use it.
I must have used nano for years at this point, and I'm shocked to find out how customisable nano actually is! I tend to use micro[0] on most of my systems now just because it comes with really lovely defaults and keybindings that are a bit more familiar, but this might make me take a second look at nano in future.
[0] https://micro-editor.github.io/
It's not just customisable, it's also insanely scriptable. Any action that you can do in nano itself corresponds to a command, and you can create "string macros" that you can bind to key combinations. Additionally it can execute external commands on any nano buffer and return the result. Combining the two is very powerful.
E.g. I have a configuration which allows me to use nano while editing pdf side-by-side, and be able to click on the pdf and land in the correct line in nano, and vice-versa. (and obviously compiling the latex document itself happens via a custom keystroke).
Interesting. Since this kind of scriptable customization sounds like bread & butter emacs -- what tips the scales towards nano, for you?
Simple. I don't know emacs that well :) I didn't even know emacs had a terminal mode until I looked this up; my main experience with emacs was when I was writing prolog and the IDE was emacs based. I didn't find it as nice to use back then so I never gave it a serious shot.
By comparison nano is everywhere and was super-simple to configure and spruce-up with custom functions, so it just stuck with me.
As for other competitors, when comparing to vim, I find it much simpler to use, and to the surprise of most vim users I speak to, equally powerful (at least for my needs).
Before I used micro & ne I used nano, and configured the keybindings to work in the CUA style. I still have the dot files, didn't delete them, but they rarely get used anymore.
I think they recently added Ctrl+S to save by default, even if unconfigured, woohoo.
I knew it! A junior dev recently used CTRL-S in nano and I couldn't believe that it actually worked.
They told me it had always been this way and I felt stupid for a bit. Good to know it's a recent addition.
For CUA aficionados, I recommend dte[0]. It has replaced my nano usage quite a lot.
[0]: https://craigbarnes.gitlab.io/dte/index.html
I personally like msedit.
https://github.com/microsoft/edit
Promising but very barebones. Hard to do without syntax highlighting these days, for example. But I think it would be useful on a tiny machine with openwrt, as micro is huge there. ;-)
> Ctrl+S to save
XOFF ignored, mumble mumble
Same same. Never even occurred to me to look. That's the risk of a (successful) low-friction product though: you use it in quick bursts where the tool is necessary but largely invisible, and you never invest in learning more about it because it works so well with the defaults. There's probably a profound strategic insight buried in there somewhere.
It seems few people are aware of how customizable nano actually is. Usually, they use nano with the default preset for quick bootstrapping tasks and then switch to vim without hesitation. While vim/neovim are certainly very powerful, nano remains my go-to editor for many quick terminal operations. I've customized it quite a bit[1], especially the key bindings, though the defaults are already excellent.
[1]: https://github.com/chawyehsu/dotfiles/blob/main/.config/nano...
I would dearly love it if you could comment a little bit more that nanorc. I am going to “steal” some of it, for sure. Thank you much for sharing it!
I tried a long time ago [1,2] to initiate this discussion on Nano here. I'm glad it's happening :).
[1] https://news.ycombinator.com/item?id=41289141
[2] https://news.ycombinator.com/item?id=41289773
Nano is my go-to whenever doing something quick in the terminal. It's quick, I don't need to learn how to use it, and now it's going to be slightly more convenient. I had no idea it had these options. Thank you!
Nano is by far the best terminal editor imo. The only situation where I'm using a terminal editor is when I'm ssh'ed into a server, and I need to quick edit a file (for serious code writing a GUI editor is far more capable). Nano is ideal for that use case: you get in, it tells you what all the relevant keybinds are right on the screen, and you get out without any fuss.
Nano is quite a venerable piece of software with the initial implementation shipping as pico, the text editor for the pine mail client, back in 1992. Tens of thousands of students at a few universities will have been introduced to it as their very first email client.
The pine authors fell foul of the Debian free software guidelines and, as well as nano, a clone for the mail client itself lives on to this day as alpine. I use it every so often for a spot of nostalgia.
This is exactly my path to it, and even though I know how to “eat flaming death” vi and used emacs for awhile, nano is still my default “edit that config file quickly”.
Same. My first internet access was a BSD shell account back in 1993; I had Pine and Pico on there. Coming from a world of MS-DOS BBSes (I ran one myself!) it wasn't that hard to take QEdit skills and move that over to using Pine and Pico-- it was quite comfortable.
I still tend to muscle memory my way through using Nano when I need to do quick file edits on Linux.
If you're on Mac and can't get .nanorc to work, check out https://stackoverflow.com/a/73373788/3876196
It's also possible that you simply do NOT have nano installed at all, and just have the simlink from nano to pico by default. That was my case. In this situation, install nano and it should work.
Right after the nano maintainer got bullied out by the FSF, I noticed two bindings got their defaults changed. They never change. I almost feel like it was graffiti, a flex against the old maintainer, a retribution for not doing whatever the FSF wanted.
Since forever, GNU readline programs and nano had identical bindings. I'm fast moving around the CLI because I'm fast at nano. Emacs has the same defaults. What sane organization only abandons their own defaults and prioritizes that work after pushing the existing maintainer out (or irritating them enough to accomplish this)?
Which bindings changed?
bind ^F forward main
bind ^B back main
bind M-f nextword main
bind M-b prevword main
What did the maintainer change them to instead?
(Because tone doesn't always come across, I'm asking out of curiosity, not to like challenge you about it.)
Seems GP got somewhere confused as well. From `man nano`:
M-F/B have not defaulted to nextword/prevword, or at least haven't within the last 10y since have those binds in the earliest version of nanorc in my .config git repo.Your 10y estimate must be wrong since my nanorc only acquired these things after the nano maintainer was bullied out.
The line numbers and position bar are some real quality-of-life enhancements!
I don't regularly use nano anymore, but I have often thought that more programs should imitate the way it shows the command shortcuts on-screen as a kind of instant tutorial. I remember my physics major friends in college thinking it was pure snobbery for vi not to do that by default. Back then we were dialing in to an HP-UX server and using pico, which nano is an open-source clone of. For those who aren't aware, pico was originally the editor component of the Pine email client.
> physics major friends in college thinking it was pure snobbery for vi
I don't think it is snobbery, that approach would clutter the entire screen. Basically every single small/capital letter and symbol has a function in vim.
To its credit, vim does show a help text with :q on it if you start it with no file. Back then, it was just vi opening to a blank screen.
set shortmess+=I
Absolutely, the shortcut help is so useful!
I believe that Nano and Pico copied it from Wordstar.
That seems very likely. One of the first things I'd noticed back in the early 90s when I got my shell account and used Pico for the first time was that the UI was similar (not exact copy, mind you) of how Wordstar was, with some basic guidance at the bottom to get you started.
Also kind of reminds me of the old Telix terminal software for MS-DOS, with the bottom status bar. Not exactly the same, but again quite similar in the approach to have you just quick glance at the bottom of your screen for a HUD.
I actually prefer 'constantshow' instead of 'linenumbers'. That way if you want to select/copy some text from the terminal it doesn't include those line numbers.
My struggle is that I work on lots of systems, sometimes ephemeral/temporary systems. There is no easy way to "sync" customizations, so I adapt to defaults.
Even basic things like how shell history is managed is very annoying to configure every single time. if only it was as simple as cloning your private github repo to ~/.config.
I use a very customized emacs/evil setup, and before that a very customized vim/neovim setup, but I've never had trouble jumping onto systems where only plain Jane vi is available. I think it's because of the color scheme, or lack thereof, that I don't have any problem automatically switching. If I don't see my color scheme, by fingers just automatically use vi compatible bindings and I don't find myself expecting my other customizations to be present.
Maybe not everybody can switch so easily, but I think it's worth trying out. (One change that absolutely does trip me up is capslock->control. If I try using somebody else's computer, I constantly enable capslock by accident.)
Cloning a github repo to ~/.emacs.d is how you can cart around your Emacs config. I've been doing this for years, and it works nicely. For things configured by files that live in the home folder directly (e.g., shell - and looks like Nano would be similar?), I've got another repo with a couple of install scripts that create symlinks to the version-controlled files. I don't love the extra steps, but I've found this works pretty well too.
Most of the time, I can manage without, but every now and again I've needed to do some thing or other, and I've been grateful to have my own preferred setup rather than somebody else's.
Check out Chezmoi (https://chezmoi.io). They even offer a nice comparison table for alternatives.
Thank you, first hearing of that tool. it might be exactly what I want.
I don't really sync my config. I just scp or wget files when I need them. I have some config as gists, as snippets in my notes, as public files in a webserver under a subdomain.
https://www.nano-editor.org/dist/latest/nanorc.5.html
They also have a nice cheat sheet there: https://nano-editor.org/cheatsheet.html
Thank you, looking for way to set tab to 2 spaces for eons without success! Very helpful :)
What would it take to have "vim-wiki" for nano (see also: FOAM, Obsidian)? I have always admired nano for how simple and easy to use it is, and would love to use it for wiki/obsidian-style note taking & linking...
Nano doesn't really support any sort of scripting or plugins beyond macro sequences AFAIK. So, not really in the same sense as something like vim-wiki etc. You might be able to cobble together something with shell scripts and text files, but it won't be well integrated.
I’ve been using nano as my default bash profile editor for over 15 years. It’s also great for quick updates for other config files.
Definitely going to enable mouse support. Didn’t know that was possible.
Is it possible to apply some of the settings like autoindent or line numbers only when editing source code? In other words, does it have different modes like emacs?
A lot of those are also command line options, so you can just make an alias.
Also worth a look, if you want more TUI..
https://github.com/microsoft/edit
I just did this for some of my setups recently, using the minibar and constantshow settings.easy to cut and paste without line numbers enabled too
10 years, I've been using nano as my editor.
10 years I've spent mastering the shortcuts.
I have been using nano in hard mode.
These configs will make my life so much easier.
I use nano a lot but this page is not opening for me. Is someone else having the same problem?
I was able to open it in archive
any sane advice on
1) integrating cscope with nano?
2) integrating exuberant ctags with nano?
3) integrating universal ctags with nano?
3) any sane advice on pattern matching (say find, or find and replace) where newlines, tabs etc can be part of query, part of the substitution?
Note that for the last few versions of macOS, "nano" is symlinked to pico.
nano is my go-to text editor, because it’s the default text editor for all our systems, but somehow I never customize it, until this post.
What about LSP?
[dead]
[flagged]
better than vim
Don't quite agree, it's simply a different tool, that's like saying notepad is better than vscode. They're both different purpose builds.
I would say that every tool has its good and bad.
A tool is only as good as its ease of use and clarity of its documentation, imho.
Wouldn't that make vi(m) just about the worst tool to exist? There's a reason that the "how do I exit vim" jokes exist, it's because the UI is awful unless you already know how to use it.
God forbid having to learn how to use something useful. Don't ever take up programming.
no
Did you know Nano supports mouse? Alt+M... Not that I use that much, but it is fun fact.
This is the very first item in the linked blog post.