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.
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.