micro – A Modern Alternative to nano
micro-editor.github.io
micro-editor.github.io
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.
Using a flow control sequences for editor commands; what can go wrong?
Hopefully a cautionary tale against careless in-band signalling.
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. :)
Whenever I use Windows my fingers are surprised to remember that the windows key isn't used for menu commands.
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.
So, about that Ctrl-C...
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).
No, the point of nano was to be like pico.
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.
OK, you write the memo about replacing Ctrl-C for SIGINT.
Every single Linux user who edits text on a cli amd hasn't bothered to learn vim.
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.
Control-G brings up help
There is also some sort of comment mode
I use it to debug containers and short-lived VMs, because it’s easier to copy/paste stuff than configuring neovim (which I would normally use).
However! “Help” doesn’t start with G. That’s a bit weird. And someone mentioned ctrl-c. That’s a bit weird too ;)
Just, not a natural idiom, when that is the operative philosophy of the project.
Clearly armchair criticism from me, as no one can name something I’ve made as cool as micro. Perfectionism isn’t always great, kids!
It could use a fix for saving hidden files on Windows :-(
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> =
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.
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.
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 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.
https://www.linuxfromscratch.org/blfs/view/svn/postlfs/nano....
https://packages.debian.org/bullseye/nano
But building from source is a different story, if you stripe and clean build dir it will be similar to prebuilt .deb
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
Like.. this is wild https://vim.rtorr.com/
And now I'm hooked on a horrible amount of vscode plugins.
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.
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 start vim with --clean to fix your vimrc.
`set mouse=a` - yes i want to use a mouse `i` - start editing `esc :wq` - exit
From there it's syntactic sugar navigation and editing.
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!
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)
Restart the computer
It’s SO inefficient in comparison to Vim, VSCode, or tons of other alternatives.
If it’s the only thing on the box, fine, but in reality usually Vim is the only editor installed.
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.
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.
---
That's what you mean?
If you are interested they might give you a good start.
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.
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.
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.
However, I do understand the criticism, and how that could leave a bad first impression.
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.
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.
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 {
echo set constantshow
echo set linenumbers
} > ~/.nanorcBut for writing text documents? Lovely little editor.
JOE has syntax highlighting, UTF-8, regex, shell windows, hex editing, incremental search, column/rectangular block, macros..
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.
Probably I'm just stupid and overlooked them, but I really don't see anything.
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.
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".
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.
https://www.rust-lang.org/tools/install
https://deno.land/manual@v1.36.1/getting_started/installatio...
I'm not disagreeing with you, as a beginner, I'm just trying to learn.
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).
Does it do this?
From https://github.com/zyedidia/micro#quick-install-script
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`).
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" 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...
Again, so?
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.
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
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.
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.
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.
So the next one should be milli.
Unity? We could also have an unpronounceable empty string, and refer to it as TEFKAM, The Editor Formerly Known As `milli`.
For what I assume are historical reasons, the empty string is usually called "lambda".
pico, nano, micro, milli, unit, kilo, Mega, Giga... Which relates to the SI units.
And Micro,Meso and Macro scaling system that centers around human sized reality.
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.
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.
Sounds easier than not seeing a bottom bar with shortcuts.
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.
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.
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.
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.
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.
If you’re familiar with Unix tools a lot of the syntax should be familiar (like string substitutions).
Having been a math tutor in the past, I pretty firmly believe anyone is capable of learning the basics of how to use vim.
It’s either a lack of effort or a learning disability, not much in between.
It’s really not hard to memorize a few keyboard shortcuts for most people who are proficient with computers.
For my 2c, I did invest the time and know my way around vim fairly well. I still prefer micro.
Prefer vim usually, but it's too much effort to deploy a sane configuration to our target systems.
Not really interested in small editors like this.
Very interested in small editors like* nano, for this root comment reason:
https://news.ycombinator.com/item?id=37173126
See also the opening paragraph here:
https://linuxize.com/post/how-to-use-nano-text-editor/
It's courteous to ensure nano in cattle builds for today's sysadmins that didn't grow up with vi or vim or pick the emacs side of that debate.
I hope they solved it but I left at that point. If it is solved, I can give it a try again.
https://github.com/zyedidia/micro/blob/master/runtime/help/o...
But even when enabled (like I have) it should indently correctly when pasting entire blocks.
If you'd like to share your setup/env/config I'd take a look at working out a patch
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.
Motif/CDE said “good enough” as well. IBM even backported some to its mainframes and minis.
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:
– Ctrl+S: save document
– Ctrl+Q: quit document
[1]: https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
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.
^s: Save
^o: Save as (type out filename, save and return to editing)
In other words, to save and quit:
^s,^x
I'm now a convert of ^S^X!
^S Save file without promptingLet'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
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.
* ^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.
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.
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.
> 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.
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 feel this kind of editor is for the sophisticated minimalist, used alongside a 60% fancy keyboard with ceramic key caps.
I see comments about this being good for "beginners", and I wonder what definition they are using. Make them use a basic graphical editor like gedit.
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 former would be:
{mark} {search} . {enter} {cut} {endoffile} {paste} (7 keystrokes)
{cuttoend} {endoffile} {paste} (3 keystrokes)
– sometimes needs to make a few quick edits right from the terminal (but prefers a proper GUI text editor like VS Code for longer sessions)
– is accustomed to the keyboard shortcut conventions of desktop applications on Linux/Windows[1]
– occasionally, wants to use the mouse and expects it to work in the terminal like it would in a proper GUI text editor.
Micro fulfills all these needs with its default configuration. It is one of the first things I install on a Linux box, be it a desktop or a server.
[1]: https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
brew install micro
The command on the webpage will only add it to the location you run it.
If you don’t want to use brew and want it available everywhere just set PATH=$PATH:<location of script>
This all was 20+ years ago. I wonder whether they're still around...
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.
It's not like nano or vim or emacs. It's for people who prefer OOTB simplicity.
For someone who started using computers in the mid/late nineties or later, it is super intuitive and I much prefer it over anything else.
How is this useful if you want to use those plugins?
(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.)
apk add nano # Installed size 308 kB
apk add micro # Installed size 12.17 MBAlso 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.
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.
Okay, how does it decide which color escape sequence to output? Does it have an inbuilt terminal database?
MicroEmacs -> Pico -> Nano -> Micro
Circles.
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.
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.
I never found any TUI editors like those two.
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.
0: https://github.com/zyedidia/micro/blob/master/runtime/help/k...
just checked the ctrl+thift+arrow keybind, works on alacritty but doesnt on kitty.
just checked the ctrl+thift+arrow keybind, works on alacritty but doesnt on kitty.
and shift+up/down works on both
(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.)
Should I switch to something else, it would probably be kakoune.
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)
Using MS-DOS 3.3 with TP 4, was still doable on a 1.44MB, which I used to carry around during high school for our computer lab.
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).
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 ;)
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.
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.
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.
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/
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?
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
A good alternative should be usable in a decent number of places where the original is usable :P
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.
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.
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.
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.
It's an awful slow mess that cannot stop itself from triggering unsolicited popups, eating all your RAM and inserting characters you didn't type.
The reality is that this is the reality of programmers today, they want something that does a shitty work for them rather than be in control.
You have an immense amount of control over VSCode and its plugin ecosystem is fantastic.
This sounds like more of a problem with your workstation or environment.
"hey, looks like you're opening a C++ file, would you like to download our C++ plugin?"
and other infinite amounts of similar popups.
Then I type (, it chooses to insert a ). I didn't ask for this.
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.
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.
sudo apt install micro