I suggest nano to my students in classes where everyone is a beginner and we're learning programming on the command line.
The greatest advantage of nano for these users is that all the commands are listed along the bottom of the screen. I was shocked to see that this is not true of micro.
The difference between micro and nano is that nano's keyboard shortcuts are pretty opinionated, while micro's are the ones used by most (GUI) applications nowadays: Ctrl+S for saving, Ctrl+F for find, Ctrl+Z for undo, Ctrl+Q to exit etc. etc. There is also a helpful hint at the bottom of the screen that you can press Alt+G to see the shortcuts, or Ctrl+G for some help.
> The difference between micro and nano is that nano's keyboard shortcuts are pretty opinionated, while micro's are the ones used by most (GUI) applications nowadays:
Opinionated, or just old and consistent? Nano is a clone of an editor related in 1989. Things weren't as settled back then. IIRC, I remember Ctrl-X was used to exit some DOS apps. IIRC, the current "GUI conventions" originated as Mac-isms in 1983/84.
> Ctrl+S for saving, Ctrl+F for find, Ctrl+Z for undo, Ctrl+Q to exit etc. etc. There is also a helpful hint at the bottom of the screen that you can press Alt+G to see the shortcuts, or Ctrl+G for some help.
> That old hotkeys didn't survive the evolution so it doesn't make sense to support them anymore.
No. It makes sense to support them if the userbase is familiar with them. Nothing is more annoying than having changes like that forced on you.
Then there's the fact that the "GUI standards" conflict with other command-line standards in a pretty serious way. Every command shell on Windows I've ever used uses a different convention than the "GUI standard" for copy-paste for exactly that reason (e.g. Windows Command Prompt's "mark" stuff, PuTTY's select/middle-click behavior).
I think that every user who can use terminal, knows combinations like Ctrl + S (Save) or Ctrl + C (Copy). So they are familiar to them as well and should cause no problems.
For me, for example, those combinations from vi, nano or emacs are simply weird and non-standard. And I assume that they are "non-standard" for everyone who was born after 1980 and have never seen a PDP or something from that era.
Therefore it doen't make sense to support those key combinations only because 40 years ago they were used in PDP and other archaic systems.
Correct. I’ve used pico & nano as my primary editors for 25+ years. A fun one to work around with nano in shellinabox browser tab is ctl+w (Where is/“Find” function in nano/pico, Close tab in Chrome/Firefox). nano let’s you remap it to ctl+f in nanorc at least.
I imagine avoiding control key sequences is part of the reason why Apple added the apple/command key to their keyboards. Makes it easy to copy text in a terminal emulator, etc.!
Whenever I use Windows my fingers are surprised to remember that the windows key isn't used for menu commands.
I've been told that IBM and Microsoft though that sending application commands with dedicated key sequences wouldn't be useful. Function keys should suffice (so I think Midnight/Total Commander interfaces are the right one to expect) but later IBM came with CUDA…
Some of us graybeards use to use teletypes to talk to our computers. In one of the earlier races between differing I/O, the printer couldn't print as fast as the teletype was receiving data, so the teletype would send XOFF (Ctrl-S) to tell the remote end "Stop sending data and let me catch up" and would then send XON (Ctrl-Q) to say "I'm caught up, go back to sending data.
Many of us carried that to our VT100 terminals and used it when lines of code or output would flood the screen faster than we could read.
Eventually paginators like 'more' and 'less' were invented and flow control via the keyboard codes for XON/XOFF fell out of favor, but some of us have very strong muscle memory. :)
A fine answer, but my life experience is that it's not just "muscle memory," I am showing that xon and xoff still work inside both Terminal.app and iTerm2 (echo $TERM shows "xterm-256color") so maybe there's some legacy stuff configured in them or something, but I'm just saying that I struggle to think of who the audience is that would be running micro but not via a virtual terminal library that implements flow control
Aside from the fact that all shortcuts are completely and easily remappable, Nano's default shortcuts actually make a LOT of sense once you start using them.
I find myself thinking I'm in nano mode and wanting to repeat searches forward and backward outside of nano so often, that when I realise I need to do something other than Alt-W/Alt-Q I have a mini-depressive episode.
I imagine that the intention of micro is more like a modern, extensible editor, rather than a beginner friendly or ubiquitous editor. I think in the latter aspects, nano is still probably what you'd want to recommend your students (until they're ready for vim /s). micro is probably more for people who learned using nano but need more functionality/want a nicer ui.
Our team uses micro as the standard quick and dirty text editor, and we really like it. Micro uses familiar key bindings, which really helps. The name kid of tells the story on functionality Nano < Micro < vim or Emacs. I do thing Micro is a fantastic option for students mainly because they already have the key bindings drilled into their heads.
I've been using micro as my main code editor(well I do use vscode for writing coq but that's the only exception) after 10+ years' time with emacs. I simply treat micro as the modern compromised version of acme. It almost has all the features to support the core idea of acme, I have written a plugin to exploit this direction: https://github.com/xxuejie/micro-acme So far it has been working perfectly for me.
I keep trying stripped down terminal editors as alternatives to emacs -- because these days I use like 1% of emacs anyways -- but I always severely miss the common emacs major modes for C/C++ etc and especially its approach to indentation there (tab to force correct indent). I really wish other editors would follow this convention.
> I really wish other editors would follow this convention.
In editors with configurable keyboard shortcuts, you can bind this to tab yourself. For example, in Vim, the normal-mode command `==` would correctly reindent the current line. (Here, `=` is an operator, so you can also apply it to other regions like `=i{` to reindent correctly everything inside braces.)
To bind tab to reindent correctly in normal and visual mode, you can put this in your vimrc:
nnoremap <tab> ==
vnoremap <tab> =
You can also remap it in insert mode if you want, but then you might want to throw some if-statements in there to determine when to indent and when to reindent :)
A big reason is because I started a working towards a PhD recently, and so I've been more focused on that. I think micro has also reached a relatively stable spot, where it would only be significantly improved with some large new features. It is serving its purpose well as a simple/familiar terminal-based editor. I have plans to give it more love and release a version 3, but no timeframe.
Like other comments here, just want to say thank you for this amazing editor! It has been my primary code editor for the past few years. I did use a few different editors for specific purposes(vscode for interactively proving coq code, joe/nvi for editing super large files), but micro does provide what I need in 90% of the cases :P
Thank you so much for micro ! I've been using it every day since 1 year and I'm a fan.
I'm really glad you achieved to bring it to a stable spot.
Congratulations also to keep it that way and not fall into 'a vim mode could be great' as some users requested.
As a faithful user of micro for the last couple of years, just know that its one of the first things I install in a new system along with the fish shell, especially in servers I have to manage via console. Thank you so much for your work!
because it's a text editor that's already fully capable of editing text. not every thing needs to constantly evolve and add features at a break-neck pace.
I had no idea people used nano as their main code editor. I use it on any nix server I'm working on and have probably used it tens of thousands of times.
I'd been a linux/bsd engineer forever and I worked at some places where they refused to install nano on servers. There are some greybeard linux admins who absolutely refuse to let someone use anything other than vi. I never got that. It's a 20MB package and not exactly much of an attack vector.
Greybeards are going to greybeard mate. Plus, it's always funny to me because a lot of the old crowd you ask them what kind of system they ran and they(with swagger) admit that they were in charge of the WHOOOOLE IT department for their local government, and it was a big town too, so at least 500 users.
And I 105% assure that that system was the most secure in the entire county... And also unusable. And when that lad retires or someone in their office kills them out of sheer desperation, hopefully they'll be replaced by one of these new fangled engineers who might not know about vi, but they at least care a little bit about their users(Not a lot though, we're still engineers)
I initially thought you were speaking of CPU/ram efficiency until you threw in vscode, so I think you mean developer efficiency. Vi/vim is what you're accustomed to. I've worked with nano since it came out, I think 2004-5ish. I have no idea what I used prior to that, probably vi.
But I am MUCH faster and more efficient with nano than I am vi/vim/emacs. My text editor of choice is like my IDE of choice, it shouldn't be a problem at all for anyone to just accept that I'm getting my work done in a different application.
I'm more in the Vim camp myself, but suspect that those who use nano for longer programming sessions do so using a well-crafted nanorc. Nano does support some "modern" features like syntax highlighting, it's turned just off by default. (As far as I know, you won't be getting stuff like LSP and multiple cursors though.)
Can I? I opened https://www.vim.org/docs.php but something bad happened to it and it displays in microscopic font for me.
After an hour wading through the docs I found a mention of evim:
---
This manual is about using Vim in the normal way. There is an
alternative called "evim" (easy Vim). This is still Vim, but used in
a way that resembles a click-and-type editor like Notepad. It always
stays in Insert mode, thus it feels very different. It is not
explained in the user manual, since it should be mostly self
explanatory. See |evim-keys| for details.
I don't know how much you actually care, and I'm the nano OP of this comment chain/thread but there are some vims (and emacs) with plugins and what not built in. Only one I can think of off the top of my head is https://spacevim.org/ but theres a bunch.
If you are interested they might give you a good start.
The main reason to know vi inside and out as a Unix administrator has to do with it being the lowest common denominator on Unix and Linux systems.
As a *nix tech I could get a call to work on a QNX system, HP-UX system, SGI Altix supercomputer or a Sun Ultra 2. Linux systems were easy, as they had the package management support for FL/OSS, and would commonly come with Emacs in the base-pack (before nano was mainstream). Sometimes you would have a terminal issue and have a single line to work with, in which case you would need to operate vi without seeing what you are doing (or use sed/awk). So maybe it is those instincts to KISS and force everyone to learn vi, like they had to (I had to).
Certainly it provides no significant surface area of attack to have an editor, but I wouldn't put it past a threat actor to leverage plugin functionality as a persistence mechanism. I presume that these applications operate differently as root, but maybe not as service (daemon) accounts. It's not very well hidden, but there are all grades of threat actors.
I did "nano debian size" on google and one of them mentions - The Nano package contains a small, simple text editor which aims to replace Pico, ... Download size: 1.5 MB. Estimated disk space required: 20 MB.
note that it does not reduce the memory size once loaded (and even prevents sharing pages when several instances are run since memory is written when decompressed, not read as a program binary is)
> even prevents sharing pages when several instances are run since memory is written when decompressed, not read as a program binary
A shame the linux kernel doesn't have some way for packers to say "I am a packer, I run with access to nothing except the binary, therefore run me with no permissions and then share the pages I make with any user that executes me. If you like, you can even delete my output and reunpack me on-demand"
I was a nano user, and this happened to me. I got greybearded into vim, and now I only touch nano when I need to de-crappify a vimrc file
I was mad about it at the time, but now I'm happy I made the change. Vim or vi is everywhere, including on the switches and routers I work on. Nano is not everywhere, nor can it easily be put everywhere.
If I weren't regularly SSHing into decrepit or resource-constrained hardware, I would likely see less of a benefit
I don't know why, probably terrible memory, but I have practically a mental block when it comes to keyboard shortcuts. I've tried spacevim and a few other bundled vims before but I have such a hard time doing anything other than moving the cursor and :wq! type of stuff.
You can still use VSCode and just use the Vim plugin.
Vim is not an editor, it's a language you speak with your editor. Like with real language learning, some of it is just rote memorization.
There are, however, some tricks that I find really help. The first is to find mnemonics for the different actions. Some are obvious, for example (d)elete or (c)hange. Some require a little imagination, like un(t)il (like in 'til).
Finally, there's some level of logic to many related things. For example, the CAPITAL version of an action is generally a "louder" more aggressive/stronger version. So (a)ppend is just "insert after current cursor position", whereas (A)PPEND! means "insert at the very end of this line".
Just like with languages, if you use them long enough, they start to "make sense", and "feel right". I don't have to translate "I want to append at the end of the line" to the correct keybinding, I simply "speak" to the editor in a way that "feels" right.
you can do it. you have to want to, first, though.
then you sit down for an hour and you create and edit a file, and you do not allow yourself to hold any key down to move the cursor around. you have the link you posted printed out, and you use only what is on the sheet to edit.
when you want to add something to the end of the line, you do NOT push the END key then enter edit mode, you look at the sheet and you find what you want and you push SHIFT+A to enter edit mode and go to the end of the line at the same time.
you keep track of which mode you're in and what mode you need to do something, and you force yourself through the keystrokes needed to operate completely and efficiently using only the keyboard.
in an hour, if you force yourself to use only the shortcuts on the cheat sheet, you will be more fluent in vi/vim than ~90% of the people who use it, myself included, and I've been using vi/vim for 25 years.
Personally, I strongly dislike nano and will take vi any day of the week over it.
However, the choice of text editor is a very personal one. It makes no sense at all for anyone to insist that anyone else should or shouldn't use any particular text editor. Just let people use what they like.
> There are some greybeard linux admins who absolutely refuse to let someone use anything other than vi. I never got that.
When I first encountered nano, I found out that it could silently corrupt configuration files (by word wrapping long lines) unless you were very careful to always start it as "nano -w". Since then, I've always removed nano (or at least set something else as the default editor) on every Unix system I administer.
"-w" changes visual wrapping, it doesn't save that way. No different than the behavior of "cat" in an interactive terminal really, beyond the temptation for editor religion.
There is the .nanorc option to do e.g. "setfill 80" and "set breaklines" but that's no different than setting a "tw=80" type config in your vimrc and saying vim breaks config files.
> "-w" changes visual wrapping, it doesn't save that way. No different than the behavior of "cat" in an interactive terminal really, beyond the temptation for editor religion.
What you mentioned is "soft wrapping", which is visual only but doesn't affect the saved file. But the default for nano when I first encountered it was "hard wrapping", which does affect the saved file. Some distributions later changed the default in the nano configuration file, but depending on the configuration file instead of a built-in default is risky. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=135978 (and the five other bug reports merged into it) for an example of the problems caused by running nano in the default configuration without disabling its line wrapping.
That's interesting. I haven't ever had that problem. I have had a ton of problems with zsh adding characters to things like SSL certs (I forgot, maybe an ending %?) where I had to switch back to bash to base64 encode/decode it properly.
I write the standards for our engineers to follow/emulate/consider. I don't have very much for nano but this is what I put into every containers userdata scripts. I can't get this curl command to show up correctly.
# Add syntax highlighting and line numbers to nanorc, need to fork syntax repo so we're not installing random git repos
curl
Haven't tried removing nano ever but hate it with a passion for one simple reason.
If none of the EDITOR/VISUAL/etc. variables are set when you invoke 'visudo' a f*king nano appears.
Like god dammit it i assume vi in that name comes from vi as even the manpage has 'vi' among 'see also'. This is akin to launching firefox and some random application popping up - its the ultimate troll and i salute your graybeards for solving the problem at the core!
His homepage just brought me SO much nostalgia. Just needs spinning skulls and construction gifs. http://www.toms.net/
And dang he owns toms.net, nice.
His resume on here hasn't been updated since 2002. Looks like he started his career in 1987. This is an interesting looking resume. Tons of skills at the top, goals, Other. I suppose it's cover-lettery.
edit: Oh, nevermind, he has a career page updated in 2019 - http://www.toms.net/career/ - so I guess he's been with Fannie Mae from 2002 - now. Good, I was a bit worried he'd left us.
JOE is pretty nice https://joe-editor.sourceforge.io/ — a hybrid of WordStar and Emacs, and if you run it with `jstar` you get a pretty authentic WordStar experience which also feels like the earliest Borland Turbo IDEs.
I used to love JOE! Maybe that's why, because it had echoes of WordStar. I just wrote an article about how I still use the "WordStar Diamond" keys in Linux today: https://benhoyt.com/writings/wordstar-diamond/
Yes! The first word processor I used was Wordstar (under CP/M). My first programming environment was Borland Turbo Pascal. Later, I used "QEdit", which was configurable to use the wordstar keys.
When I finally migrated from DOS to Unix, in the early 90s, I was delighted to discover JOE. It is the first program I install on any new Linux or *BSD box or VM.
JOE has syntax highlighting and several other nice features these days. I have therefore never felt the need to get proficient with vi or emacs.
Great memories there, back in the 90s I used to use joe for everything that wasn't editing code. Mainly because it just isn't good at that, it's more of a "word processing" model, with word wrapping and lack of syntax highlighting, etc.
But for writing text documents? Lovely little editor.
I love micro and use it every day. Now that I've tried Helix, however, I want micro plus baked-in treesitter, LSP, and contextual help. Helix really nails it with that feature set but I'm just too happy with my "single-mode + commands" ctrl-c/ctrl-v muscle memory to switch.
Why is there still software asking user to run sudo on something downloaded from the internet? Why even bother doing that script if there is a easier, safer, with smaller footprint and built-in in all distro option available?
Just as comparison, micro alpine's package has 4MB (installed) while its staticly compiled binary version it downloads from github has 11MB. The repo's package would make it more micro.
Quick-install script
curl https://getmic.ro | bash
The script will place the micro binary in the current directory.
From there, you can move it to a directory on your path of your choosing
(e.g. `sudo mv micro /usr/bin`).
It points out you need `sudo` to move the binary to `/usr/bin` - if that's even what you want to do - but... yeah? So?
This is just a demonstration of how unfriendly is Linux to supporting third-party software. You are supposed either to use software from distribution's repository or compile it yourself. And if you are a software developer, then you are on your own to decide how to support hundreds of different distributions (the most popular way is to statically compile everything into a single binary).
Such scripts remind me of DOS-era "installers", and they are awful:
- it is unknown whether your distribution is supported or not
- this script is probably not tested on many distributions and can break something
- it is unsafe, because you are running a code that some random person posted on the Internet without any sandboxing
No, it is not a demonstration of anything. I'm not saying there is no fragmentation on linux, there is.
There are many solution that try to fix that: appimage, flatpak, snap and what not. All of them of some degree of success, and pitfalls. I, for example, am happy user of flapak, running steam games on a alpine distro without much problems.
But for this specific thing I just don't get why there is a curl/bash command. It is a wide available piece of software that you can easily install using distro’s repo. Don't want to user terminal? Just download any "mainstream" distro and will have a store like software available, type micro, click install and done.
Is there fragmentation in linux? Yes. Is is hard to guarantee it will work on every distro? Yes, a lot worse on software you can't compile. But micro IS NOT the demonstration of it.
There is no reason whatsoever micro should have "curl | bash" on the front page.
Note that you must install micro to a directory accessible to all users when doing
this, typically /usr/bin. cd to that directory before running this script.
E.g.:
$ cd /usr/bin
$ curl https://getmic.ro/r | sudo sh
or
$ su - root -c "cd /usr/bin; wget -O- https://getmic.ro | GETMICRO_REGISTER=y sh"
You conveniently missed off the lines of text above that which explain what "doing this" is:
getmicro can use update-alternatives to register micro as a system text editor.
For example, this will allow `crontab -e` open the cron file with micro.
To enable this feature, define the GETMICRO_REGISTER variable or use the URL
`https://getmic.ro/r`.
Note that you must install micro to a directory accessible to all users when doing this...
Yes, if you want to install `micro` as a system text editor, something you can do (but don't have to), you need privs.
I know why it is asking for sudo and that was not my point.
Again, my point is: you should never ask the user to run sudo from curl (or actually, don't curl to bash at all). There are plenty ways to sploit that.
Again, I know it needs root to move the bin to a root owned folder or update the default editor, but, again, you should never ask (or suggest) the user to pipe shit from the internet, it is security risk.
Also there is not even reason for it, micro is available in every distro.
It is completely irresponsible to encourage piping random Internet sources to sudo or to (ba)sh, and I'm quite tired of hearing the ridiculous justification that "everyone does it".
"It depends". The answer for this has multiple parts. Though my preference is using my OS package manager (so I'm biased towards that), I'll try to explain my reasoning as best as possible.
And I'm using "OS" in a liberal sense, to also mean "different linux distros" and "BSDs".
---
One, you have to also think about what happens after installing. You have to consider upgrades, uninstalls, and also errors happening during those processes. With these scripts, if something goes wrong you're mostly on your own (though yes, you can go to the specific support channels for the specific software to fix the specific problem for your specific situation).
Your Deno link at least is versioned so it would be less bad to debug if something goes wrong, but that's only relatively speaking.
A package manager deals mostly with static archives, and keeps track of any file controlled by it. It is trivial to know whether a particular file belongs to a specific package or not. Upgrades can be centrally managed. Since it knows about what programs it has installed, it can print you a list of names and versions of everything so you can compare it against a list of CVEs or something.
Custom installation scripts are custom, and each has their own way to do these things.
---
Second, those instructions tell you to run a random script without even verifying its integrity first. No versioning for that script, no auditability trail, no signature to guarantee that the script is indeed the same as the script's author uploaded some moment in the past and has not been tampered with since.
A package manager deals (usually) with static archives whose signatures are verified before trying to do anything with them. An install operation is a simple, boring, "extract archive". Maybe with a small post-install script (that was part of the signed archive).
And the public keys used by the package managers are (usually) already in your local machine, so for most operations you are using an already-known public key to validate signatures.
(Note: Presence of a signature does not imply the software is trusted. It only means that the person that signed the thing had access to the private key.)
---
Third, though this sometimes causes problems (but I have never experienced them, or at least nothing comes to mind), the maintainer of your OS package repository usually knows your OS better than the upstream developer, and can apply patches to the packaged software that can be bug fixes, or even disabling/removing telemetry that the upstream software has enabled by default.
And with a package manager you know there's at least one other person (the maintainer of the package) that has used this program in this specific OS. There may be the case that some versions are just packaged without actual testing (just "git pull & run packaging scripts" or the equivalent), but in those cases there's the escape hatch of installing a previous, working version of the package.
---
With that said. If you were to ask me if there would be a situation where I would use those scripts, then _maybe_ (big maybe) it would be (1) inside a container where I don't care about any garbage left behind because I can nuke the whole thing at once; or (2) in an isolated environment where I don't even care if the script needs root privileges (this second case implies I would not do this in Docker).
No, it is unfeasible (at least for me) to validate every single package. So at some point I have to trust someone/ some party and I chose to trust more the maintainers of my distro than a person asking me to run sudo from curl.
And some people trust the software authors more than some random repo maintainers who don't have enough time to even make sure the packages they update are actually still compatible with each other.
You do not need to trust anyone if the program is run inside a sandbox. This sandbox is supported in hardware since 80386, but Linux doesn't make proper use of it.
In Linux, to install virus or malware, you need to download, compile, and install virus manually, OR user can install it using `curl ... | bash`, which is much simpler method. Even newbies can install new malware using `curl ... | bash`.
sudo, yes. piping to a shell is fine imo provided the install script is easy enough to read if you are so inclined. i have seen lots of generated install scripts that are mind boggling.
the reality is that you run code you haven’t personally read and vetted everyday. so the idea that you need some stranger to bless a package for you to be trustworthy doesn’t make a whole lot of sense.
Personally, I don't want a middleman to be inserted between the application developer and me.
I want to get my applications directly from the application developer, because that way I can make sure that I'm using the officially supported version of the app and that no one has meddled with the code.
If I don't trust the application developer, I simply don't install the application.
> because that way I can make sure that I'm using the officially supported version
No, they (the developers) can’t guarantee that, nor is their job.
You would trust them to develop a reliable software and you would trust the maintainer to guarantee the it will be properly compiled for specific OS version, has the proper permission set and has all dependencies it requires to run.
To ask the software developer to pack and make sure it works for all distribution would be huge amount of work that is beyond their knowledge (which it is not a issue). Also it seems one is not aware how to properly do it when they comes up with a not so bright ideas like the “curl | bash”.
It is not you don’t trust the developer, it is that there are people who know how to better distribute it.
obs.: this is in the context of micro and general FOSS that is easily available and distributable.
SI doesn't have a prefix for 1x does it? Doe you'd need a non-SI like macro or meso, or just to jump from milli to kilo.
Or call it Editor One or just Editor.
Just curious, why are people interested in small editors like this? The only reason I ever use vi/vim is because it's everywhere. If I'm going to install an editor, I'll install Emacs. If it's a remote system I'll simply open the file over SSH with tramp (essentially transparently supports remote editing) and retain the full power and speed of my local Emacs. For TUI editing (like for sudoedit, git commit, C-x C-e etc.) I run Emacs as a daemon so new frames, including TUI frames load instantly, look very close to my Emacs GUI (with nerd fonts, colours and everything) and are literally Emacs. You really don't need to have multiple editors for different use cases.
I have been a Linux nerd for over two decades, but I never managed to grok vi, it just seems unintuitive. I found Emacs more attractive, and when I ssh into a low-powered device like a router running OpenWRT, Emacs isn’t available so I use the editor that is available and seems intuitive: Nano. (Yes, I know I could also use Emacs with TRAMP, but everyone establishes their own personal workflow.)
This comment isn't meant to knock vi. Obviously it has its fans. But the inability of some hackers to feel comfortable with it is a well-known phenomenon.
Just because you can doesn't mean you want to. There's alternatives.. if OP doesn't like vi's bindings why would you insinuate they're lazy or have a learning disability?
For my 2c, I did invest the time and know my way around vim fairly well. I still prefer micro.
Not everyone is interested in a humongous editor with a steep learning curve. Some people just want to quickly edit a file.
You can use this with the knowledge you have already of windows notepad or mac simpletext and it will work on a busted or server machine with only a unix console.
It's funny because `emacs -Q -nw` loads instantly on my very modest system and supports pretty much everything `nano` does immediately. You can move around with arrows, you can just start typing etc.
The one thing it's missing is telling you how to save and close the file etc... Makes me wonder if a nano-style help bar with super-simple key bindings would be a useful default bundle for Emacs.
`emacs -Q` seems to load even faster, somehow, and that's the full graphical version if you have a window system.
> Not everyone is interested in a humongous editor with a steep learning
Then why using a TUI editor at all? Each time nano was opened because of some default settings, I saw this whole bottom bar with shortcuts. It sure doesn't seems to be easy to learn either.
I don’t understand why so many people in these comments are claiming text editors are “hard” to learn.
Software engineers that went to college have taken Calculus, Physics, and other advanced courses that can be very hard for many to learn.
The reality is that memorizing a few keyboard shortcuts is not in fact hard. It’s something that can take time, and you might not like the shortcuts, but it’s not hard.
If you want to use powerful tools, you’re going to have to learn how to use them. There’s no way around this.
I don't get this either. You watch a skilled tradesman work and he'll use all manner of tricks he's learnt over the years. His tools will do most of the work, he just gently guides them in the right direction. Then I'll see developers not even using tab completion in a shell. It's almost like tooling has to shout at them (like underlining errors etc) out of the box before they'll interact with it. It's so strange.
You’re in the wrong thread. Normal folks outnumber developers 100 to 1.
Not to mention, some of that dev group prefer that their small editor have the same keybindings as their full dev environment and entire OS for that matter. No mode switching needed.
Nano is pretty decent for that reason and I definitely wouldn't grumble at having to use it for tiny tasks like a few lines of config file. Including nano (or any editor) inside cattle doesn't seem like it should be necessary, though. If you can open a shell then you should be able to use tramp or something similar.
Nano is on all the OSes I ever encounter. I don't edit things remotely often and it's usually trivial config files.
I tried micro, and liked it but it didn't quite open instantly on a pi and I don't use CLI editors for anything big enough to really need the features.
We use micro because we could develop a custom plugin without too much effort and it is very easy to deploy (copy) to systems that have no good terminal editor available.
Prefer vim usually, but it's too much effort to deploy a sane configuration to our target systems.
vim vs emacs is an age-old flamewar. I for one was never able to make use of emacs, it feels like a whole new hobby or job to configure it. Vim on the contrary is pretty convenient to use on default settings.
The issue of micro for me was the formatted paste. When I paste a piece of code, micro tries to indent it line by line. Yet, it does not have the whole picture. So it indents the pasted text gradually to infinity. And line by line inferring the format slows the process down to zero. You paste and go grab a coffee instead of watching a Matrix-like paste scene.
I hope they solved it but I left at that point. If it is solved, I can give it a try again.
It is enabled by default so that wouldn't be unlikely, but I was thinking more of the circumstances such as SSH tunnels, xclip or wl-clipboard and similar (or perhaps the most important one, version of micro itself)
I only used it locally, so there wasn't any other application in between. I used it on Windows but I don't have the version -though I always keep it up to date, so latest or minus one- or configuration now, yet I'll update you with details when I get back from vacation. Thanks!
I've had that happen once when I was using it on Windows with Wezterm.
It depends on how you paste. I'm not 100% clear how it works, but I believe micro reimplements pasting directly with xclip (idk what it does on Windows) so if you paste with Ctrl+V, it just instantly inserts what's on the clipboard as a block and copies the source indentation. If you do Ctrl+Shift+V, sometimes it essentially just gets the clipboard piped from the terminal each character one at a time, not knowing what comes next, so then it indents extra when it sees the return character and then it naïvely gets a couple tabs added on top.
Been using this for years, really great for making quick edits in the terminal. Mouse support and standard editing shortcuts as the default (unlike many other terminal text editors) are the best features in my opinion.
I’m not referring to some definite standard, but to the conventions that have existed in most desktop apps, at least on Windows and Linux, ever since I first used a computer. Wikipedia has a good list of them.[1]
The list also shows Emacs and Vim for comparison, so it’s easy to see the deviation from the Windows/Linux conventions.
When it comes to text editing specifically, at least these ones are deeply inscribed in my muscle memory, and I use them every day in a variety of applications:
– Ctrl+C: copy selection to clipboard
– Ctrl+V: paste from clipboard
– Ctrl+X: cut selection to clipboard
– Ctrl+Z: undo previous operation
– Ctrl+Y: redo previous operation
– Ctrl+A: select all
– Ctrl+F: find
– Del: delete char to the right of cursor
– Ctrl+Del: delete word to the right of cursor
– Ctrl+Backspace: delete word to the left of cursor
– Home: go to start of line
– End: go to end of line
– Ctrl+Home: go to start of document
– Ctrl+End: go to end of document
– Ctrl+Left: go to previous word
– Ctrl+Right: go to next word
(And the Shift variations for selecting text regions, like Ctrl+Shift+Right for selecting the word right of the cursor.)
I’m definitely not the fastest typer, but I feel these make my text editing a snappy process.
Additionally, while not related to the editing itself, I appreciate these ones:
Umm..on macOS, ctrl-X appears to remove the whole line and Cmd-X doesn't even work. So, it does not consistently implement these shortcuts honouring the OS conventions.
True, it's older than that, but I didn't recall exactly when it became universal across all significant contemporary OSes. I don't know what Amiga Workbench used, for example. Figured Win95-era was a conservative guess.
When the IBM PC took over basically, but interestingly they used the Mac as a starting point, since Microsoft had been using the keys. MS learned GUI programming on the Mac before they developed Windows. Hence the lawsuit Apple lost.
Motif/CDE said “good enough” as well. IBM even backported some to its mainframes and minis.
I think nano is modern itself, still actively being developed, and for the past few years more or less feature complete. But if nano wasn't there, I would probably be using micro.
Too many awkward keyboard commands though. To save and quit: ^o, Return, ^x
Vs Micro ^s ^q
Honestly that, and ^k (kill to end of line) are the only commands I use in any CLI editor.
Ironically my muscle memory actually learned the obnoxious 3-step nano way so I usually forget to use micro.
But every time I work with a developer under 40 and see them fiddling with vim trying to wrestle with vim to do simple text entry with a git commit message, I help them set $VISUAL and -$EDITOR to micro, although I have to remember the config to turn on the help/status bar that shows the commands, since they inexplicably turned it off by default a few years ago.
If that’s true, I’ve been literally wasting a really annoying keystroke every time. Why on Earth don’t they include SAVE in the list of commands they advertise in the footer?
I appreciate that and will be forever grateful to you personally from now on when I hit ^S, but I just never thought to search the Help for it, since I figured something so critical would surely not have been omitted from the footer menu if it existed!
Let's just take a moment to appreciate what is apparently more important than the happy-path activity of saving your file:
^G Get Help ^O WriteOut ^R Read File ^Y Prev Pg ^K Cut Text ^C Cur Pos
^X Exit ^J Justify ^W Where is ^V Next Pg ^U UnCut Text^T To Spell
Of these, I to this day have no idea what ^J, ^C, and ^T would even do. Who the heck tries to justify text in a plaintext editor? Lol.
* ^J is not very useful, it combines a block of lines into a single line.
* ^T requires a spell checker to be installed. I get: Error invoking "spell", even though I have aspell, gspell, hspell, huspell, hunspell and also nuspell installed. Who knows how to configure this.
* ^C outputs information about the current cursor position, but "Cur Pos" is not a helpful description.
To be fair, I just discovered that many(all?) of the commands listed in ^G (help) are actually in the footer menu, but the menu is truncated to what available space is available on 2 rows × char width. Save is positioned very far to the right as the last item.
According to nano, the rationale of the order is:
> "The bottom two lines show the most commonly used shortcuts in the editor."
I still use ^O a lot due to heuristics of reading a file X, to use as a template for a new file Y (think nginx server block). The intent to use ^O, in those cases, actually precedes firing up nano.
Another small TUI ide/editor to try is Orbiton [0] also written in go and has clang-lint, compiling, and has gdb debugging support, though I believe it lacks plugins. These features work also for Rust, C/C++, and I would imagine Zig, and Go development as well. I tested it on an old 2012 kindle fire and it works great.
This is not a nano alternative, it follows the vim paradigm of having a command mode that nano does not have (for good reasons). It's more of a merge between vim and nano if anything, breaking the core intention behind nano.
If you ask me, nano has a niche of a super simple terminal editor that anyone can look at for the very first time and instantly figure out, with very few pitfalls or ways to mess up. The more features you add, the more modes and options, the easier it is for newcomers to press a key combo that puts them in a state only intended for power users that they won't be able to get out of without googling.
I guess my main complaint about nano has always been that it seems more suited for document editing rather than code -- defaults to word-wrap on, doesn't really have syntax highlighting by default, not a lot of support for code-oriented workflow.
Fine for writing up an email or commit message, I guess, but then I have to have another editor to write code in anyways?
After 30 years of using emacs (well, these days a lot of CLion, too, let's call me a backsliding emacs user) I'm ready for an alternative. But nobody has come along with something that really fits the same swiss army knife niche.
Well in my experience I very rarely if ever need to actually code in a terminal. Sftp or rsync are usually on hand so there's little reason to not just go for sublime or vscode if I need to make a substantial change. What nano comes in handy for is changing config files and adjusting system settings, when I'm jumping around and making very small edits.
I write a ton of code and it's all nano. I simply disagree that it's not suited for code.
> defaults to word-wrap on
a simple toggle in the config, or in the live session.
> no syntax highlighting by default
says who? Are you using an ancient version by any chance? If anything syntax highlighting is one of nano's strengths, as creating your own or modifying an existing syntax is super easy. I had to write custom syntax for nano and vim once: nano took me a few minutes, the vim one took me a whole day to write.
> no support for code-oriented workflow
Like? I've never wanted something (reasonable) that couldn't be done.
Saying a "modern alternative" implicitly suggests that nano is not modern, or that it is somehow outdated or unfit for "modern" use-cases. This couldn't be farther from the truth.
E.g. I'm currently using nano to edit a latex document, with full in-nano compiling and evince-synctex support (i.e. jump to/from pdf in nano). This required only a measly three lines of macros to be added to my .nanorc.
I am also a (reasonably knowledgeable) vim user, but I prefer nano for my coding, and now only tend to use vim when collaborating with a vim colleague. Everytime I hear vim rants about keystrokes and vim-magic, I chuckle because usually I can do the exact same thing with (my configuration of) nano at least as fast, if not faster. (no hate to vim, vim is also an excellent editor; I'm just pointing out that people tend not to realise or talk much about the power/potential of nano im the same way as they do for vim)
Incidentally, I did try micro last time it was posted on HN. I tried very hard to like it, but in the end it just couldn't hold a candle against the latest nano.
Note that often enough what people refer to as nano is some antiquated version that happened to have been bundled in their system. I saw a (reasonably modern) system recently whose nano version was 2.3! Meanwhile the latest nano is v7.2, and the added features just in the last two updates were gamechangers.
I use VS Code, but I don't use it for $EDITOR, because CLI programs popping up GUI windows always feels icky to me (and it's gotten orphaned once or twice). micro is a really great editor for people who don't use terminal editors for much.
I'm not on VS Code but I use micro as $EDITOR for the exact same reasons and it's great. I don't have to remember special shortcuts just to amend a git message or do an interactive rebase.
Nano doesn't have a default keystroke for "match an end-of-sentence" character, though creating such a binding in .nanorc is trivial.
However, since what this typically means in practice is you'd either cut until the next period, or until the end of the line, in the absence of an "end of sentence" keybinding, my approach to this would simply be to either cut until the next period, or until the end of the line as required, which I believe is a wholly reasonable alternative.
The 7 keystrokes become very vim-competitive when you realise that d)Gp actually fucks up in the typical scenario, since usually what you want is NOT to paste after the first character of the last line, but actually in a new line below the last one. Which means you don't actually just do `p`, but something like `o ESC p` instead.
From sailplane straight to (at least) a Cessna looks more like another level, supercharge and weight class all in one. I guess it's fair to locate 'micro' rather somewhere in the in-between, a middle ground and then there are in fact not that many contenders on the CLI, or else they're fossils. I would've thought this is what makes it attractive to some? Whereas others don't really have a use case. As for 'nano' on the other hand frankly there are about as many proper and more modern alternatives as there are Linux distributions and I'm sure anyone who's still a console regular has their favorite or two. I'm a vimmer but for quick snaps or in very strange places I *really* like dte. Am not associated with the project: https://github.com/craigbarnes/dte
Ages ago, there was TextPad -- a commercial product. Back when I was munging textified order histories for a multinational (lots of orders, ergo huge text files), it was great up through version... 4.7.3, I seem to recall. Then, they started redesigning some things in ways I found enworsening (if I may be permitted to riff off of the current linguistic trend). But, IIRC, it remained fast with big files.
This all was 20+ years ago. I wonder whether they're still around...
As an unironic GNU nano power user, I feel like this project is for people who want to like GNU nano but don't know how powerful the editor really is. Seriously, I highly recommend everybody to sit down with GNU nano and read the manual. There's a lot that you can do, almost as much as Vim in fact.
So it reinvented vim/emacs and friends and called it an alternative to nano without understanding what nano is.
That's like saying Visual Studio is an alternative to Notepad with a straight face. I mean sure, both could type text but it's fundamentally a different product.
What disappoints me most is that terminal editors often use weird hotkeys that are unique only to them instead of using widspread hotkeys. What I want, is, for example, to use Ctrl + S for saving and not some other combination.
You may be in luck, because the default keybinding for Save in micro is indeed Ctrl-S. I installed it and aliased it over Nano for a bit on one of the servers I SSH into constantly, just to test it out.
Why not? Those control combinations can be disabled if I remember correctly. Also, as they conflict with modern hotkeys, they should be changed everywhere.
Been using it as my main editor for the past 3 years now, coming from Sublime Text. It's been a great editor so far, but it's missing a lot of modern features, and the plugin support seems to be next to none.
I must be weird because I see a major divide in editors. CLI editors are for light text editing and don’t need plugins. Updating a line in a config file, etc. I’ve never even wished for a plug-in for them. IDEs need plugins. They’re for coding.
(I know some people use vim or emacs for coding, with 1000 amazing plugins, but I think deep down they’re masochists in the first place, especially vim.)
I use Sublime daily exclusively for quick notes and as a scratch pad/clipboard. What I have started noticing recently and what worries me is that with only the most basic Markdown plugins it now uses 1 GB of RAM and is somewhat less snappy than it used to. I really hope it goes away soon but with other editors getting more resource-heavy, I am worried.
Micro to me strikes a perfect balance of easy enough to get working out of the box and not so simple it's stifling. I wish it came with LSP support built-in though.
The main advantage of nano is the tui user interface where commands and menus are displayed graphically. Second advantage it's pre installed on most systems. I would use vi if I knew how to quit , copy and paste, and navigate around the screen.
having spent decades with nano, transitioning to emacs was a revelation. the extensibility, the vast array of packages - it was like stepping into a whole new world.
but then came vscode. it felt like the best of both worlds - simplicity when you need it, complexity when you want it. plus, the integrations and extensions are top-notch.
Also lately I've been a bit spoiled by Visual Studio enterprise at work, thinking to buy a personal license
I mean don't get me wrong, i have a soft spot for nano. there's something about its minimalism that's just...comforting. but functionality-wise, it doesn't hold a candle to emacs or vscode.
that said, i'm intrigued by micro. it promises modern features while staying true to nano's philosophy. if it delivers, maybe i'll find myself switching yet again.
Same as any other trendy editor, old or new: wake me up when it's CUA.
I learned dozens of editors in the bad old days. Then common sense has ruled since the late 1980s, and anything which does not comply with the universal PC UI can die in a fire.
I've been using Micro for quite some time, with some configuration and addons it becomes very comfy and it's enough for me most of the time. I miss some features though but they are probably more of addons than core features.
A person who knows and likes the program can do that, but the default name is a drawback for adoption. Nano is shorter name, using it is user-friendly and it already is on almost every modern Linux installation. So micro has a tough rival to beat, and it seems to be an "uphill battle".
Pico was based on MicroEmacs 3.6. Nano is an open source clone of Pico - there's definite DNA in that series. I'm assuming not in this new Micro, but it's faintly amusing that the name seems to be a play on something that was a play on a name which was a play on a historical namesake of the new thing.
On the other hand, Micro supports the Ctrl-based text nav/manip hotkeys (such as Ctrl-arrow, Ctrl-Backspace, CTRL-Home/End, also optionally combined with Shift for selection).
More of a DOS-origin set of hotkeys than GNU. So more familiar to some and less familiar to others.
It supports mouse interaction out-of-the-box, which is a big plus for some folks who haven't spent much time in keyboard navigation. The escape hatch is a nice option for some tasks, even for keyboard navigation pros.
The top intuitive to use TUI editors in my heart will always be:
- MS Dos Edit
- Turbo Pascal 6
Edit felt like a windows application: select with shift+arrows, move fast with ctrl+home/end.
Turbo Pascal's keybindings were a bit influenced by WordStar's, I think, so a bit old style already at the time. But, my friend, the TUI Toolkit, TurboVision! What did they do there! Multiple windows that could be dragged and resized, blazingly fast. All of this on a 486 with megabytes of ram.
The reason why MS-DOS text editors were so fast and felt powerful is that they used direct access to video memory to render the text-mode UI.
Unix is still stuck on the notion of the console being an output stream that emulates a Teletype printer at some level. Full-screen text UIs work around this by adding extra layers for screen manipulation in a stream-oriented device.
On MS-DOS, the system APIs were so primitive and limited that everybody (beyond basic CLI tools anyway) just wrote directly against the IBM PC hardware, which conveniently mapped the text-mode screen at a memory location. You could print or move or clear on-screen elements using standard memory operations, and there was no other software layer sitting in between translating the frame buffer, so updates were instant. (No other hardware layers either. The CRT blasted out your characters at most some 15 ms after your update. Today, who knows what’s buffered in the GPU and display itself.)
It’s the difference between a multi-user system where you (as the user) get a narrow stream of I/O with the shared computer vs. a single-user machine where you truly control the device. Sadly the latter model of personal computing is increasingly obsolete.
While the 'tty' concept seems archaic, it has served Unix-ish systems very well in the long run, giving us a nice console experience with a diversity of terminal applications and an excellent remote experience.
Meanwhile Windows never really implemented a proper universal console abstraction -- until recently -- and forced all console output through the same terrible hardcoded terminal with crap support for basic things like copy and paste, and struggled for over two decades to have a productive console environment, forcing administrators and power users to do everything of substance through the GUI or tear their hair out. This is finally fixed, but only recently.
When looking at Freedos a while back I found an editor called setedit. It does work on other platforms than DOS but I haven't tried it. It is influenced by the Borland C++ IDE editor.
TurboVision in TP 6 was my path into OOP, started early on by TP 5.5 adoption of Apple's Object Pascal features.
The framework design is marvelous, not only what it could do on UI level, it already had reflection, serialization, collections with common stuff like map/filter/sort via callbacks.
Great learning experience, and good ramp into "there is more than one way to do OOP".
Another good TUI experience on MS-DOS, also with great OOP ramp-up learnings, Clipper (version 5 introduced OOP support).
486? Ha! I remember getting my hands on a TP copy in late 80s early 90s, first version I had fit on a 720k floppy but the second one did not (1.44), and I remember trimming it down to fit 720k because I had only a 640kiB 80c88 with two 3.5" 720k drives and no hard disk. It was plenty fast already!
Then I got a 1MiB 286 Goupil G5 (with something like 20MiB HDD, I remember thinking that thing is so huge how am I ever going to fill that, which I never did) and a colour CRT, TP felt so blink and you miss it fast on that machine already, it must have been lightspeed on a 486!
I for the life of me can't remember if aforementioned versions were (resp.) 4.0 and 5.0 or 5.0 and 6.0 though. My hunch is on the latter but I'm really not sure. Last one I used was TP 7.something much later (early '00s)
I've never used micro, but if you look at the default keybindings[0], you'll see they're very Windows-y and might be to your liking.
As for myself, I don't see cut-to-character or select-to-character like in vim, and yanking and pasting seems more intuitive in vim. And with visual block I don't miss Sublime style cursors at all.
The selection model is unfortunately a bit broken. For example shift+control+arrows and shift+down doesn't work. I believe the problem is that selection with shift isn't written to compose with other navigation.
Those key combos didn't originally send any special codes to the app. Newer terminal emulators do.
(I once wrote a hack for Linux that opened a connection to the X server and used the xkb -- X Keyboard Extension -- protocol to get info about the shift/control/etc state in order to synthesize shift+arrow and shift+control+arrow keycodes. It worked almost perfectly with a local X server.)
Right! I also used a Norton Commander clone written with Turbo Vision. You could mark several files (with Insert), then press F4 and voilà - you got multiple windows open! AFAIR, you could even do a "global search and replace" (across these windows). Powerful stuff.
Although coding in TV was much, much less pleasant than using it...
Now I use Emacs, which is obviously superior to any other editor except Vim, which is incomparable [0] to Emacs.
By the way, I noticed a long startup delay... (on tilde, and on micro as well). After some stracing, I found out that the culprit was a TCP connection attempt to an X server that I didn't have. (X forwarding was configured in my SSH client, but there was no X server running on my PC...) In case it can help someone ;)
Yeah, "micro" for an editor would be 11 kilo bytes. I bet it's possible to do a half-decent editor in C in 11KB. Antirez's "kilo" (~1000 lines of C) is 36KB when compiled with standard gcc (https://github.com/antirez/kilo).
That said, for many server-type use cases these days, 11MB isn't a huge deal. Still, I wonder if micro could be compiled on / ported to TinyGo and end up a few hundred KB? It looks like TinyGo can produce some pretty small binaries: https://tinygo.org/docs/guides/optimizing-binaries/
>That said, for many server-type use cases these days, 11MB isn't a huge deal.
Yes but that doesn't make it a good candidate for a default editor that would be ubiquitous, from small embedded development stuff to servers to desktop.
I don't mind several MB when the tool offer more than the competition. But what are pico/nano lacking really when it comes to editing a few lines in a config file once in a while? It is not like micro is trying to replace visual studio code or emacs either. Or is it?
On some linux distros (debian based) there is a im-tiny package smaller than the full blown vim.
Also historically vim was not the default vi clone installed, which was an optionnally installed package. The default was very often a smaller clone: elvis. Busybox as its own vi clone and most BSD OS are still providing nvi by default
micro wants to be a small, lightweight, modern alternative to other things, but it's written in Go, which means it isn't going to be available for older systems and/or for classic architectures.
A good alternative should be usable in a decent number of places where the original is usable :P
I guess this is for people that don't use Neovim but never want to leave the terminal? Just kinda seems like the worst of both worlds to me. Less powerful than neovim while still using the same configuration language, yet less ubiquitous than even vscode at this point which does have many easy download options.
What a strange comment, as if everyone wants or needs to use vi...
Believe it or not, most people don't like or use modal editing and vi-style keybindings. Yes, Vim is extremely popular, but it's still a minority of people who are typing text into computers. The vast majority of people out there are working in editors with "traditional" direct, modeless, editing and some variation of "standard" (aka Windows/Mac) or Emacs-ish keybindings. (Hell, even bash/zsh/readline -- effectively a single line text editor -- ships with a sub-variation of emacs keybindings by default.)
Personally, I use emacs -- when it's available. But something like this looks good for lower footprint systems.
Anyways, what a strange comment. Nano/Pico, etc. have been around since the super early days, I remember using Pico on a 486 back in 1993. Used to be the default editor on most systems that had the 'pine' email client installed, too, which was very common all over the place.
Seriously, the fetish people have for vim and for pushing a modal editor on people who didn’t learn on such programs is downright weird. Vim is definitely an insane default editor for anyone who’s not already a skilled fan of it. Micro even has mouse support, making the incredibly common task of “put something at a certain place in this config file” trivial, versus vim where you only need to memorize 12 random key bindings to become more efficient at keyboard cursor control than what a 7-year-old can do with a mouse.
I classify vim usage more as a religion than anything else. That doesn’t mean I don’t respect how effective that 0.5% of developers can be with it, but nearly no one I’ve met is as efficient in it as they’d be in VSCode, and about 95% are so unskilled in Vim that they get tripped up by just the basic mode switch and remembering :wq. They should not even be bothering with it. But sadly it seems 80% of people think it’s mandatory to use it to edit random files on servers, and as the editor for things like git.
Absolutely it feels disrespectful maybe in the context of Bram Moolenaar's recent passing, but... To me the vim thing is kind of cultish?
I have encountered many gatekeeping-elitists out there who act like this is some kind of entrance exam for competence in our profession or something. It's disturbing.
Early on I went with the emacs religion instead of the vi religion. That merely came down to the fact that my favourite MUD/MOO client was in emacs (it was amazing, BTW). And because emacs was on the HP-UX systems I was playing on. And because the modal editing in vi seemed crude and slow to me.... but in the intervening years I'd never thought of telling anybody around me that they should be using emacs or judged them for not using it?
But I've now encountered several people in the last 20 years who said things like "I wouldn't hire somebody who relies on an IDE to write code" always along with an aggressive promotion of vim.
Anyways, I think vim is neat. I respect it. But I won't use it... Don't Mode Me In.
It calls its terminal multiplexer functionality "terminal emulator", it seems. Unless it has a GUI, but then "terminal-based" is wrong.
I am not a fan of nano, as it is not even qualified to attend the editor war, but this one adds JSON configuration, "curl | bash" installation, has a JS-dependent website, and generally looks even more awkward than nano. Apparently both nano and this editor have their target audience, as do all those other "modern" editors, but observing this triggers the feelings likely similar to those that lead to flamewars: it is painful to observe seemingly inefficient and otherwise awkward tools used by others, and tempting to suggest to look into better options.
You know what nano's good for? Editing a few lines of a config file every now and then.
For that purpose, it's great, works a peach, and is as at least as good as every other option if not better.
And that's what 99% of people use it for, because that's what 99% of people need in a terminal based text editor. Those people don't tend to participate in these sorts of discussions because, well, they're probably still trying to figire out how to exit vim after someone told them vim was better than nano.
> You know what nano's good for? Editing a few lines of a config file every now and then.
As long as you always start it as "nano -w" to prevent its enabled-by-default (at least on some versions) word wrapping from corrupting your config file.
Definitely this. I'm super happy for anyone finding some new level of productivity with vim, emacs, kakoune, etc. but I don't want to join an editor cult, not even a CUA one. I just want to edit text from the command line using a familiar set of keystrokes and move on with my life and micro fits the bill.
The greatest advantage of nano for these users is that all the commands are listed along the bottom of the screen. I was shocked to see that this is not true of micro.