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 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.
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.)
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.
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.)
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.
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)
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).
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 ;)
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.
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.
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.
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.
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.
* ^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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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/
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.
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.
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.
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.
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
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.
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.
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.
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!
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.
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
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 :)
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.
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.
335 comments
[ 4.9 ms ] story [ 329 ms ] thread[0]: https://news.ycombinator.com/item?id=23334190
[1]: https://news.ycombinator.com/item?id=29128702
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.)
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.
https://setedit.sourceforge.net/
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).
1. https://github.com/gphalkes/tilde
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.
[1]: https://www.youtube.com/watch?v=QSe5FGlyBFU
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.
[0] https://en.wikipedia.org/wiki/Partially_ordered_set
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.
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!
Let's just take a moment to appreciate what is apparently more important than the happy-path activity of saving your file:
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.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.
[0] https://github.com/xyproto/orbiton
https://github.com/ahmednooor/lino
https://github.com/curlpipe/ox
https://github.com/zee-editor/zee
https://github.com/ilai-deutel/kibi
https://github.com/gchp/iota
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.
This all was 20+ years ago. I wonder whether they're still around...
https://www.textpad.com/home
But 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.
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.
MicroEmacs -> Pico -> Nano -> Micro
Circles.
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>
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
https://github.com/zyedidia/micro/tags
https://www.gnu.org/software/emacs/history.html
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:
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 :)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.