An Atonement of Nano(noa-s.org)
noa-s.org
An Atonement of Nano
https://www.noa-s.org/nano.html
103 comments
I love the ability to record a macro, I use it all the time. But unfortunately only one macro can live in memory at any one time.
I was hoping for the ability to record a macro, and then 'save' it somewhere for future reuse (possibly by binding a shortcut to it).
The link you point to seems very interesting to me for this reason. If that means what I think it means, then that is a good workaround for me, so I wanted to make sure: can you bind a shortcut to a string which uses ansi sequences to simulate keystrokes, and something like, e.g. "^R" to simulate pressing control+R?
If that's the case, while I cannot "record and save" per se, I could still use this technique to bind a key to a series of keystrokes, like I would with a macro inside the editor.
I was hoping for the ability to record a macro, and then 'save' it somewhere for future reuse (possibly by binding a shortcut to it).
The link you point to seems very interesting to me for this reason. If that means what I think it means, then that is a good workaround for me, so I wanted to make sure: can you bind a shortcut to a string which uses ansi sequences to simulate keystrokes, and something like, e.g. "^R" to simulate pressing control+R?
If that's the case, while I cannot "record and save" per se, I could still use this technique to bind a key to a series of keystrokes, like I would with a macro inside the editor.
Yes you can use ansi use pre-defined macros to fire key combos. Edit your .nanorc and bid a sequence to a key (like in the given example). To specify combos, press alt+v then hit the key combo you desire.
Oh hey,
I'm primarily a Vi user, but I respect and love nano. It's the first editor I try on any system I'm not familiar with.
I'd also argue against growing nano to a good IDE, because I think nano is in perfect form for its name and role.
Maybe there can be a fork (maybe called micro) which contains the features you want to see in nano.
I'm primarily a Vi user, but I respect and love nano. It's the first editor I try on any system I'm not familiar with.
I'd also argue against growing nano to a good IDE, because I think nano is in perfect form for its name and role.
Maybe there can be a fork (maybe called micro) which contains the features you want to see in nano.
FYI, Micro already exists, it's implemented in Go
https://micro-editor.github.io/
https://micro-editor.github.io/
IMO, nano does seem like the terminal equivalent of notepad. The key value proposition being that it's easy to use without having to learn how to use it, especially compared to what you have to learn for vi/emacs. - Most of the time you won't need to be editing files in the terminal, so it's a good 'emergency' tool just in case you need to.
TBH, I wasn't aware of sophisticated features like automatically commenting/uncommenting. But I think putting effort into memorising those is less useful than putting effort into learning at least the basics of vi or emacs. -- There should be no shame in using nano.. I just can't agree that it's worth putting time in to memorise those keybindings.
Though now I wonder why there isn't a VSCode-equivalent (emphasis on "works out of the box" and "easy to use") for the terminal.
TBH, I wasn't aware of sophisticated features like automatically commenting/uncommenting. But I think putting effort into memorising those is less useful than putting effort into learning at least the basics of vi or emacs. -- There should be no shame in using nano.. I just can't agree that it's worth putting time in to memorise those keybindings.
Though now I wonder why there isn't a VSCode-equivalent (emphasis on "works out of the box" and "easy to use") for the terminal.
The key selling point of Nano for me is displaying the core controls in the footer at all times
This used to be a fairly standard thing in the days of DOS, shame it is not more widespread - my memory for keyboard combinations is atrocious
This used to be a fairly standard thing in the days of DOS, shame it is not more widespread - my memory for keyboard combinations is atrocious
Seconded. I mostly use vim now, but especially for beginners discoverability - or at least displaying how to exit the current program - is an underrated feature.
Absolutely. This is also why it's the right choice for the default editor: it lets anyone use it even if they've never seen it before.
100%. When I need to remotely help less experienced users solve some issue on a remote server, those controls in footer are incredibly useful.
No need to memorise anything. All the shortcuts appear on the menu right at the bottom (and if you want more detail, there's the help page, also linked to on the menu at the bottom)
There are shortcuts shown on the bottom, and I thought that was all the shortcuts.
What surprised me is there are shortcuts like M-3 to comment/uncomment a line, or ^Q to search. These don't appear at the bottom.
What surprised me is there are shortcuts like M-3 to comment/uncomment a line, or ^Q to search. These don't appear at the bottom.
> Though now I wonder why there isn't a VSCode-equivalent (emphasis on "works out of the box" and "easy to use") for the terminal.
The terminal is effective because you can combine all kinds of tools together. Or as some say, the shell is the IDE.
If you're searching for a single application that performs all these tasks out of the box, there is no longer sufficient benefit in using the terminal. A terminal variant of VSCode would be inferior to the GUI variant.
The terminal is effective because you can combine all kinds of tools together. Or as some say, the shell is the IDE.
If you're searching for a single application that performs all these tasks out of the box, there is no longer sufficient benefit in using the terminal. A terminal variant of VSCode would be inferior to the GUI variant.
There was a Sublime-Text-equivalent for the terminal, but I cannot remember its name for the life of me.
Thank you for sharing - this looks fantastic!
Micro?
TextAdept was my go-to for that.
Spacemacs or SPF13 are kind of like that.
Back in the day (mid-90's), many that I knew using nano were former users of Q-Edit.
It was pico then, nano came out a bit later. But I used it because it was what pine used and I got used to it. Then I decided to learn vi and emacs sometime later.
I have used both Pico and Nano. The selling point of Nano to me is it being small and available. I don't do my day to day work in nano, but even in the most minimal system it is normally there, which makes it useful for configuration changes in a pinch.
Another editor that works similarly to Nano, that most people don't seem to know about, is Micro (GNU) Emacs. Although it's not as small or common.
https://github.com/troglobit/mg
Another editor that works similarly to Nano, that most people don't seem to know about, is Micro (GNU) Emacs. Although it's not as small or common.
https://github.com/troglobit/mg
nano is available because it was made to be, pico is similarly small. nano was created, in large part, as a response to the license of pico, while (at the time) intending to be a drop-in replacement. Since it was under the GPL and became included in most distros, it was developed further than pico, because users of pico had to seek it out. It wasn't present on most systems without installing it yourself (or having an admin who did).
Might have been, it was so long ago.
A wonderful use case for nano is introducing students who have never used a command line before to unix. You can teach a classroom of students to edit files in nano productively in a single 45 minute class period, which means that an introduction to programming class can move very quickly into actual programming. If your goal is to have student produce a working program on day one of class, nano is a godsend.
By then end of a semester, the students will be running into the ceiling of nano as an editor and you can tell them about other more featureful editors.
By then end of a semester, the students will be running into the ceiling of nano as an editor and you can tell them about other more featureful editors.
I don't understand your argument here. You do not need to use a terminal-based editor when you work on the command line. You can run "gedit file.txt" just like you do "nano file.txt" and it will work as well. I guess this may be even easier for newcomers, wouldn't it?
Until you start editing files remotely through ssh, and then they will understand why the obvious thing (calling a graphical program from the command line) may not work as expected.
Until you start editing files remotely through ssh, and then they will understand why the obvious thing (calling a graphical program from the command line) may not work as expected.
I think the point may have been that nano is a safe assumption to be on most any GNU/Linux machine where as gedit might not be and that nano has all of the commands listed on the screen for quick reference.
For example when I was taking my sysadmin class we used CENTOS which did not have gedit since it did not have a GUI. We used VI instead, but I learned nano was good for simple fixes and I did not have to google the method of saving and exiting.
For example when I was taking my sysadmin class we used CENTOS which did not have gedit since it did not have a GUI. We used VI instead, but I learned nano was good for simple fixes and I did not have to google the method of saving and exiting.
For an entry to programming class, I'm not sure why you would forego a GUI though.
For context, I just got my cs degree a year ago and most of my classmates only know a terminal as that bottom pane in vscode
If you want people to get up and running quickly, either require vscode or have people program in one of those browser based IDEs
For context, I just got my cs degree a year ago and most of my classmates only know a terminal as that bottom pane in vscode
If you want people to get up and running quickly, either require vscode or have people program in one of those browser based IDEs
Students should be taught what the terminal is, how to use it, how to program it, and to not be afraid of it during their program. But whether it belongs in a first class or not is debatable. In a first class, students have so many other things to learn that adding on the terminal can be a bit overwhelming (typically the actual material of data structures & algorithms, but also the syntax of some language, the first time they've ever had to be so precise in writing anything down in their lives). I liked how, in the late 90s/early 00s, GT made a point of teaching you to use the terminal in the 3rd CS course (various numbers, 2130, 2230, some others). By that point, you were comfortable with programming itself so learning to use a computer properly wasn't a big addition there.
I was disappointed when I got to grad school and many of my peers didn't even know how to invoke a compiler or interpreter from the command line. If you didn't give them a common IDE, they were absolutely lost.
I was disappointed when I got to grad school and many of my peers didn't even know how to invoke a compiler or interpreter from the command line. If you didn't give them a common IDE, they were absolutely lost.
The need for precision is such a wonderful thing to teach young people. I start my class with the students typing in exemplar programs and discussing with each other how they think they work. It's amazing how many errors they make in that process; a good reminder of how imprecise we are by default and how unforgiving code is.
The biggest advantage of foregoing a GUI is that the experience of programming is totally modal: you're either in the shell, editing your program, or running your program. That allows students to focus on what they're doing without distraction.
A secondary advantage is that the tools are so wonderfully simple. On the first day we introduce ls, touch, nano, and cc. That's all you need to write your first program. The tool reference fits on one page. And that toolchain will do right by you for anything up to about a kiloline, and in an introductory course, that's about the biggest thing you'll write. So there's no more mussing with tooling. You can focus on algorithms and data structures.
A tertiary advantage is that it forces (and allows) the students to muck around with unix in a way that's oddly less threatening than a graphical user interface. Eventually they start rooting around in /etc and /var and /bin, and learn a whole lot about how computers are organized. So there's some serendipitous learning as well.
A secondary advantage is that the tools are so wonderfully simple. On the first day we introduce ls, touch, nano, and cc. That's all you need to write your first program. The tool reference fits on one page. And that toolchain will do right by you for anything up to about a kiloline, and in an introductory course, that's about the biggest thing you'll write. So there's no more mussing with tooling. You can focus on algorithms and data structures.
A tertiary advantage is that it forces (and allows) the students to muck around with unix in a way that's oddly less threatening than a graphical user interface. Eventually they start rooting around in /etc and /var and /bin, and learn a whole lot about how computers are organized. So there's some serendipitous learning as well.
Our computers (intentionally) don't have mice.
This is a good thing. But what does it have to do with whether you use curses or gtk-based programs? In both cases you can use either the mouse (eww) or the keyboard.
Truth be told, I've never tried to use a gtk-based editor without a mouse. Which would you recommend? I'll try it out.
I'm not the most representative person for that... I can only suggest gvim ;)
Anyhow, just tried gedit and you can press "^S" to save the file and "^Q" to close the window, which is pretty much all that you need to start editing text files.
Anyhow, just tried gedit and you can press "^S" to save the file and "^Q" to close the window, which is pretty much all that you need to start editing text files.
I’m now a Vim user in the terminal, but while growing up on mid-90s Slackware I used `joe`. I really figured that little editor out, and it was surprisingly feature rich. Still shares a fond place in my heart.
In the late 90s/early 2000s I started encountering Unix machines that weren’t my family’s 486. I found that `joe` really wasn’t installed anywhere, so I endeavoured to figure out `vi`. This worked well as it was often the default editor on the systems I was attaching to. Some systems used `pico`, and later `nano`... and I found that annoying.
Fast forward a few years, and `nano` seemed to be the default everywhere. At first I found this very irritating, but over time I’ve come to realize that many have the same sort of feelings about `nano` that I did about `joe`. No, they’re not super-extensible mega-editors, but they’re fine for editing a few config files or a crontab. More than fine once I bothered to wrap my head around the feature set and stopped grumbling every time I was in a `nano` session. (Though I still set `vim` as my default when reasonable on servers.)
So, I’m sorry little `nano` for all the past grumbling. You may not be my first choice, but I respect you for the workhorse you are!
In the late 90s/early 2000s I started encountering Unix machines that weren’t my family’s 486. I found that `joe` really wasn’t installed anywhere, so I endeavoured to figure out `vi`. This worked well as it was often the default editor on the systems I was attaching to. Some systems used `pico`, and later `nano`... and I found that annoying.
Fast forward a few years, and `nano` seemed to be the default everywhere. At first I found this very irritating, but over time I’ve come to realize that many have the same sort of feelings about `nano` that I did about `joe`. No, they’re not super-extensible mega-editors, but they’re fine for editing a few config files or a crontab. More than fine once I bothered to wrap my head around the feature set and stopped grumbling every time I was in a `nano` session. (Though I still set `vim` as my default when reasonable on servers.)
So, I’m sorry little `nano` for all the past grumbling. You may not be my first choice, but I respect you for the workhorse you are!
I'm the opposite. I used to use vim and then for years I was working on windows stuff. When I came back to linux I wasn't that fluent with vim anymore and I didn't use it for development anyway, just live changes for config files etc. So I decided to switch to nano for that. It's great and it feels really small and light compared to vim (by "feels" I mean subjectively) and I like that.
I think many of those who advise against nano have bad experiences from earlier times when it didn't properly support UTF-8 and EOL-diversity, resulting in broken files.
I personally use vim (as my console editor), but the feature set I can actively use without referring to documentation probably doesn't exceed by much what nano could do.
I personally use vim (as my console editor), but the feature set I can actively use without referring to documentation probably doesn't exceed by much what nano could do.
It also doesn't help that most distros tend to package nano 2.9 or older, whereas the latest version is now at 5.5 with considerable improvements.
Yeah, it took me a while to get past this, and still sometimes hesistate to use nano (emacs here) just because I got bit by this in those days, but now I generally don't have a problem with nano and will often use it over vi on a remote box without emacs or issues with using tramp.
Inserting hard line breaks when word wrapping is quite annoying too, and that's the default. I've seen a lot of people break config files because they didn't start it with -w.
The default has been changed in nano 4, and hard wrapping is now off by default.
Question:
When "hard wrapping" is off and I move the cursor to the right beyond the screen, then the line on which the cursor is gets moved to the left - ONLY that line.
Is there a way to have the other lines move as well to the right?
Reason: sometimes I want to compare what I'm editing with what is present at the same position in the rows above/below - moving the cusor up/down to have those contents displayed is a bit annoying... .
Thx
When "hard wrapping" is off and I move the cursor to the right beyond the screen, then the line on which the cursor is gets moved to the left - ONLY that line.
Is there a way to have the other lines move as well to the right?
Reason: sometimes I want to compare what I'm editing with what is present at the same position in the rows above/below - moving the cusor up/down to have those contents displayed is a bit annoying... .
Thx
I find that a bit annoying too. My solution is to fire the same file and line using `less` on a parallel window (e.g. in byobu) with the -S enabled (which I have enabled by default) which allows you to scroll to the right instead of wrapping the text. You can then edit the line in nano, and refresh (with Shift+R) as appropriate in less to compare with the lines above.
aha - Shift+R in "less", didn't know that - thanks!
[deleted]
I use nano all the time for production linux services. Its simple, effective and works really well in a shell session over a satlink connection. The key combinations make it a lot easier to not f*k up in those kinds of sessions.
This article is genuinely difficult to read due to the lack of capital letters. It shows a lack of consideration for the reader.
I honestly hope this comes from using some accessibility tool like dictation software. Otherwise it’s honestly a childish thing to do - and in that case I fully expect the retort will be something like “I know people complaining about this are just pedantics, I use it as a filter to decide who I should pay attention to”. I’ve seen similar attitudes before. Occasionally someone will hide behind dyslexia, which begs some questions, but I just don’t have the medical training required to assess the veracity of such claims.
Also, trying to evangelize a tool while being a weirdo is not going to help your case.
Also, trying to evangelize a tool while being a weirdo is not going to help your case.
That is a good point in general about dictation software or other accessibility issues. Not likely to be the case for an article about a text editor however.
The filter to decide who to pay attention to works both ways...
The filter to decide who to pay attention to works both ways...
Wow I didn't even notice until I read this comment.
It's a lack of consideration for tradition. nano is spelt all lowercase, and starts sentences a lot; I think it'd be harder to read if sentences alternated between initial capital and initial miniscule.
That’s just silly. Most tools are spelled lowercase and just get capitalized in proper English when required. Facebook is not capitalized in the logo, for example.
It’s just being awkward for the sake of it.
It’s just being awkward for the sake of it.
Elsewhere on their blog (and especially on their gemlog) the author discusses and uses teh constructed language Toki Pona[1].
From wikipedia: > Capital initials are used to mark proper adjectives, while Toki Pona roots are always written with lowercase letters, even when they start a sentence.
I imagine they've deliberately carried this across to their English language writing too.
[1]: https://en.wikipedia.org/wiki/Toki_Pona
From wikipedia: > Capital initials are used to mark proper adjectives, while Toki Pona roots are always written with lowercase letters, even when they start a sentence.
I imagine they've deliberately carried this across to their English language writing too.
[1]: https://en.wikipedia.org/wiki/Toki_Pona
I love nano (especially the latest version, not that 2.9 stuff that's default on most linux distros). I don't mind vim and I'm happy to work in it if I have to, but every now and then I redo the 'vim tutorial' to help me not forget, and for the most part, with a handful of (non-deal-breaker) exceptions, my thought is always "I can already do all this stuff in nano".
Whenever I speak to people casually about why they like vim over "e.g. nano", I find that people who think vim is far superior often fall into one of these categories: - They like vim because it allows them to do things I think are bad software engineering practices which I would avoid anyway - They like vim because it allows them to do things they are not aware nano can also do as easily (especially given you e.g. can run arbitrary shell commands on a selection). - They've gone overboard and have added every single vim plugin in the book to convert it basically to an IDE or something that is no longer an editor. - Nerd cred.
I only miss a couple of things when in nano, none of which are dealbreakers: - "highlight all search results" (but search and replacement otherwise works extremely well, and I can always do the highlighted search in parallel in a less window) - "shift all text to the right rather than only that line" (but again, one can simulate this in a less window trivially - it's just a bother to have to do so) - Inability to create pre-recorded custom macros; you can only have one recorded macro live at any time.
But that's about it.
But having said that, I would not call myself a seasoned vim user. So I ask with full honesty. Persuade me to jump to vim. Can anyone argue specific points of things vim does better that nano can't do?
Whenever I speak to people casually about why they like vim over "e.g. nano", I find that people who think vim is far superior often fall into one of these categories: - They like vim because it allows them to do things I think are bad software engineering practices which I would avoid anyway - They like vim because it allows them to do things they are not aware nano can also do as easily (especially given you e.g. can run arbitrary shell commands on a selection). - They've gone overboard and have added every single vim plugin in the book to convert it basically to an IDE or something that is no longer an editor. - Nerd cred.
I only miss a couple of things when in nano, none of which are dealbreakers: - "highlight all search results" (but search and replacement otherwise works extremely well, and I can always do the highlighted search in parallel in a less window) - "shift all text to the right rather than only that line" (but again, one can simulate this in a less window trivially - it's just a bother to have to do so) - Inability to create pre-recorded custom macros; you can only have one recorded macro live at any time.
But that's about it.
But having said that, I would not call myself a seasoned vim user. So I ask with full honesty. Persuade me to jump to vim. Can anyone argue specific points of things vim does better that nano can't do?
I don't know nano, I don't really use vim (kind of, I'm an Evil person ^^).
Does nano has a very rich movement system such as Vim has? I think that's one of the main selling point
Does nano has a very rich movement system such as Vim has? I think that's one of the main selling point
Probably not! What kind of movements do you have in mind?
If you mean stuff like "delete 5 characters", probably not. But I never really got the appeal of that over pressing delete five times. The time it takes me to count the characters to decide it's five of them is probably longer than the time it takes to press delete the appropriate number of times without thinking ...
If you mean stuff like "delete 5 characters", probably not. But I never really got the appeal of that over pressing delete five times. The time it takes me to count the characters to decide it's five of them is probably longer than the time it takes to press delete the appropriate number of times without thinking ...
nano is the first thing I install on any machine I have access to.
I don’t use editors from the command line long enough to learn vi or emacs and I know how to quit nano (and it reminds me if needed).
And the colors are nice now, too.
I don’t use editors from the command line long enough to learn vi or emacs and I know how to quit nano (and it reminds me if needed).
And the colors are nice now, too.
If you like nano use nano. There's nothing there though that can replace the modal editing of vim or the hackability of emacs.
In 5-10 years nano or other simple discoverable text editor will become the mainstream choice in terminals, and vi/vim will become an obscure tool preferred by a small minority, mostly consisting of the veteran "greybeards". See changes in Fedora. New kids are breastfed on nano and/or MS/Apple IDEs.
I'd say that's the case already.
It seems this list of features is not exhaustive. It also seems to have support for a file browser to select files, mouse, autowrapping/autofilling, spellchecker, etc.
Quite a lot of things are listed in the info manual.
Quite a lot of things are listed in the info manual.
I like nano and prefer how it navigates text to vim. If vim works for you then great but... nano is just fine for me!
I just use VSCode over ssh for everything outside my local host. The support in Code for ssh is awesome and maintained by Microsoft AFAIK.
That requires a closed binary which (iirc) you copy automatically to all your remote machines. Encouraging the use of closed dev tools felt weird in 2019 but after 2020 it's IMO irresponsible.
Sometimes I wonder why linux isn't more popular.
Then one of our interns calls me cause they are stuck in Vim and I remember.
Then one of our interns calls me cause they are stuck in Vim and I remember.
For all the issues that (rightly so) affect the popularity of linux, I don't think this one is high on the list. This is something that can be figured out in a single google query.
I mean that it just adds to the pile of silly problems people experience with it, that don't need to be there. They add up.
If you know what Vim is called, yes.
I just tried this very naive query:
https://www.google.com/search?hl=en&q=linux%20editor%20opene...
And the first hit teaches how to close vim. No need to know what is called.
And the first hit teaches how to close vim. No need to know what is called.
You're assuming they know it's an editor.
that's assuming you can exit vim to launch your browser in the first place :p
Nano could be wildly more accessible for beginners with an easy config like this that sets saner keyboard defaults. It also enables the little-known mouse support, which makes the shortcuts hints at the bottom act like buttons.
https://github.com/RangerMauve/nanorc/blob/master/.nanorc
https://www.nano-editor.org/dist/v2.1/nano.html#Using-the-Mo...
I seriously find that the shortcuts hints being always present to be very helpful, great UX for occasional fiddling with dotfiles and files in /etc.
https://github.com/RangerMauve/nanorc/blob/master/.nanorc
https://www.nano-editor.org/dist/v2.1/nano.html#Using-the-Mo...
I seriously find that the shortcuts hints being always present to be very helpful, great UX for occasional fiddling with dotfiles and files in /etc.
The author assumes that disregard of nano as inferior and not up to the daily task is somehow "elitist". It reads as though the author has been personally afflicted by its lack of use, which seems like a strange stance to hold.
I'm not required to like, laud, or advocate for every piece of software. Conversely, I'm allowed to not like things as well.
I didn't know it had these features, sure. But... so what? I don't use nano, I don't like when things default to it as an editor, and I'd rather not have it on my system because it's just extra bytes used up on my disk.
If that makes me elitist, then so be it.
I'm not required to like, laud, or advocate for every piece of software. Conversely, I'm allowed to not like things as well.
I didn't know it had these features, sure. But... so what? I don't use nano, I don't like when things default to it as an editor, and I'd rather not have it on my system because it's just extra bytes used up on my disk.
If that makes me elitist, then so be it.
> I don't like when things default to it as an editor
I strongly favour Vim myself, but I don't blame anyone for using Nano as a default editor. If the goal is to make a program (or distro) as approachable as possible then Nano is a sensible choice, much more so than Vim or Emacs.
I strongly favour Vim myself, but I don't blame anyone for using Nano as a default editor. If the goal is to make a program (or distro) as approachable as possible then Nano is a sensible choice, much more so than Vim or Emacs.
Sure, I never argued against that.
> I'd rather not have it on my system because it's just extra bytes used up on my disk
I'm assuming you're talking about your development system/workstation.
Why would 2MB matter? It has no dependencies that aren't installed by default in every distro.
I'm assuming you're talking about your development system/workstation.
Why would 2MB matter? It has no dependencies that aren't installed by default in every distro.
Because I don't like having cruft. It's simple.
Nano is a great tool for people who aren't used to using command line tools. I unashamedly used it for ages before switching to Vim. I always recommend it to people who are new to doing work on Linux remotely.
Ironically, it's an even better tool for people used to using command line tools!
I wish most distros didn't default to nano. I like vim, I liked when that was the default, now it's such a pain running something like visudo and getting nano.
Defaults in most distros need to be sane and just work. You can change this by just copying your $shellrc with EDITOR=vim.
It's easy to change the default. It's a lot harder to teach every user how to exit vim.
Try using the `select-editor' command. If you don't have that, you can also try setting $EDITOR and $VISUAL in your bashrc.
I use vi for quick edits and Emacs for serious development. I find nano somewhat frustrating to use. But I'm glad it's there because it's perfect for people who are new to terminal-based Unix environments. (Back in my day, that often meant college kids logging in to their school shell account.)
If I'm programming I'll use a graphical IDE, preferably something by Jetbrains or at a push VS Code.
If I'm logging onto a server to change something small I'll use nano. I don't have any reason to learn vi or emacs.
I never have to do anything that requires me to need anything more than nano. If there ever is that requirement then it's gonna be hosted somewhere else and deployed to the server anyway, so I'll edit it on my machine in my ideal IDE.
If I'm logging onto a server to change something small I'll use nano. I don't have any reason to learn vi or emacs.
I never have to do anything that requires me to need anything more than nano. If there ever is that requirement then it's gonna be hosted somewhere else and deployed to the server anyway, so I'll edit it on my machine in my ideal IDE.
[deleted]
In my opinion, mockery was never about Nano itself, but about standards. Vi(m) is everywhere, it is a standard (you may like it or not), so please learn a few basic commands, and you'll be able to use it when necessary.
What's next? "I don't like cp command, so I will always install thismagicommand on my servers..."
/rant on
Having nano as a default crontab editor (on some distros) does not win popularity contest with more experienced admins, quite the opposite.
What's next? "I don't like cp command, so I will always install thismagicommand on my servers..."
/rant on
Having nano as a default crontab editor (on some distros) does not win popularity contest with more experienced admins, quite the opposite.
It makes me happy seeing nano being considered this way. Some of the features cited in the article were developed, improved, influenced or implemented by me; mainly macros and external commands.
It is possible to use the linter combined with macros as a "go to implementation" or "go to declaration"[1]. I think it is also possible to do the same so it can get completions from external commands.
I'd like to improve nano enough to make it a good IDE, but its main developer is against it.
[1] https://lists.gnu.org/archive/html/nano-devel/2018-05/msg000...