If you are a sublime person, micro is your terminal based editor. Built in sublime style multi-line editing, built in super simple plugin management, intuitive tabs and splits, keyboard shortcuts you are familiar with, clipboard works across apps, shifting the current line up or down one line at a time visually (bubbling I think it's called) etc.
Features that require plugins in sublime also come standard and are incredibly useful, like using it as part of a pipeline or my single favorite editor feature of textfilters, like the sublime filterpipes plugin. Meaning if I know how to do something using a regular cli tool, you just do that without having to do it in some new way. For me that means I can use Micro as an interactive front end for xsv for giant csv files of questionable provenance which require some hand fixing as well as some large scale transformation.
Since 2.0, the stability on enormous files has also been off the charts great. It will open and be ready to work on 1gb+ text files faster than wc can tell you how long they are.
Anyway, as you may have noticed, I am an enormous micro fanboy, sorry not sorry.
I don't see it (other than the color scheme). It doesn't come with a file manager or typeahead for the command interface. I've already hit a showstopping bug just trying to save a file. It's been a while since I was actively using Sublime but it doesn't feel like it at all.
It looks promising though. I would love for it to become feature-rich and replace the mess that is vim.
> I would love for it to become feature-rich and replace the mess that is vim
I'll admin vim has problems, but unless it supports vim-style keybindings and modal editing, it's not going to replace vim (there is an issue for that though https://github.com/zyedidia/micro/issues/643)
Hey if I may suggest a different editor to you then: https://github.com/martanne/vis
It is vi like and combines modal editing with a cool regex command language (based on sam) and multiple selections. I've been using it as my daily driver for about two years now and it's been just great so far.
vis looks really interesting. It looks like it has a lot of potential, and fixes a lot of my gripes with vim (like non-posix regexes), but both the core application and the ecosystem don't seem very mature yet. I'll definitely give it a try, and maybe contribute but I'm doubtful I'll be able to use it as my main editor.
That's definitely a fair point. I just like to point it out to people, since it's flying under the radar quite often. I think it has a lot of the right ideas about what text editing should look like, and there are plans for some really exciting stuff in further develpment (like a client/server architecture and a language agnostic rpc interface).
Yea I meant for me specifically. It's hard to learn new key bindings, but as someone who uses vim and VS Code, I'm willing to learn new ones if the editor solves my numerous issues with vim.
I'm someone who loves vim, and uses it every day, but I'll admit there are a couple things that are a pain (especially to learn). Coming to mind right now is buffer management. I've been able to patch over it with plugins (wintabs is great), but that's not really the best solution, usually.
I guess I would say, if you're using micro, you might already be working in a multiplexed/tmux terminal, and you might already be using mc or broot or something for your file manager stuff, but that's just me. Quick-save and recovery has never been a problem in my experience. Give it another shot!
Thanks for finding that! I have fixed the two issues (file not getting saved, and syntax highlighting not updating). Please open a Github issue if you find any more like those.
Can I use my mouse and keyboard shortcuts like I usually do when I am editing text?
edit: nevermind. i thought this was the be-all end-all i am looking for in terms of a modern terminal where I can click/drag stuff with my mouse like I can with a text editor/textarea box in a web browser.
I had no idea highlighting something and dragging it with the mouse was a thing. It works all over the place from quick testing. This is cray, how have I missed this my entire life?
I've used micro for years and I love it because it's feature-ful on local and remote servers without needing to learn vim or emacs. And much more user friendly than nano. I've recommended it to a few dozen people
Might give it a try. Been using ne or Nice Editor when I cant be bothered with any of the usual ones. I have used them all and know enough to move around at least. It all depends on the system I am on.
The one benefit Emacs has always had is you can configure it once and edit files over SSH on any system. Not many other editors have this level of editing.
Beware: micro sometimes inserts invisible characters into your files. I never figured out why, and it seemed to only be on Debian.
I lost 2 days to troubleshooting weird problems, until less revealed some configs had little droppings of random text sprinkled throughout. I opened them with micro and everything looked fine... then I opened them with nano and I could see and remove the extra characters.
Micro has a great user interface, really. I wish that I could use it, but I don't think it's wise and I will stick with standard nano for quick edits.
Could those be non-breakable space characters? Alt+Space generates them in many environments. That caused a lot of grief on MacOS for me until I added a rule in Karabiner to disable the feature.
Do you remember what version that issue happened on? Were you using unicode characters or a non-UTF8 encoding? That sounds like an annoying issue and it would be great to fix it.
This was in 2018, not sure which version. UTF-8 across the board.
I don't remember the details, unfortunately. I think there was a pattern to it, like they were control characters or something. But it silently inserted them, and they were not visible within the editor, but they were visible in nano/less/etc.
Did they just appear as space characters, or did they actually not take up any cells in the editor? Currently some non-displayable characters are rendered as spaces, which is not ideal. I will look into displaying non-displayable characters in a special way (perhaps as `^@`, similar to how Vim does it, or with �, which is meant for this purpose).
I think they were appended to the end of each line, so unfortunately that would make it non-obvious that something was there. If they were rendered as spaces that would explain not being able to see it. Displaying them as � would be an improvement.
Again, this was awhile ago, but I don't think they were single characters, it was a sequence of characters.
Is it possible that it was a matter of changing the line endings? Some applications can be quite sensitive to different line endings… sounds suspiciously like that?
I observed the reverse on Windows. A Powershell profile file edited on vscode, when opened on micro, shows an invisible character (I thought it was space) after every character in it.
When it works i love it. I have used it as my go-to editor for at least the last 2 years for quick edits and remote development. It is distributed as a static binary you can put in your `~/.local/bin`, making it is easy to install on systems you don't have admin access to. It has decent syntax-highlighting, lots of themes, easy to configure and has a very gentle learning curve. I'd say micro is a better alternative to nano for beginner, with the exception that nano works better in more limited terminals like putty and cmd.
However, at times it simply stops being able to access the X clipboard. It doesn't support code folding. And after longer sessions it seems to run out of space on the LUA stack. (Some lua calls don't properly clear the stack when done it seems, though I haven't seen this yet on v2.0).
I bring with me my keybindings everywhere, since they seem to have swapped around CTRL and ALT for word navigation and for moving lines of text, (This decision might be due to limitations in some terminal emulators). There is also a history of inactivity of the main author, leaving many PRs ignored for long stretches of time. Some are over a year old and has seen no feedback from the main author.
I just tested it, and it uses ctrl+left, ctrl+right to navigate words - which is the same on most interfaces of linux and windows. I'm not sure if it's reversed for you, or you're expecting the opposite behaviour
Great! Maybe this will serve as an introduction to terminal editors for people who otherwise stray from the more advanced variety (Emacs, Vim).
But I wish people would stop distributing apps via `curl | bash`. It has a number of pitfalls[0] beyond security (there's a case to be made that it's no worse than the alternative on that metric), like the potential to execute an incomplete script download. We should encourage people to download the script first, or at least wrap logic in a shell function and verify a GPG signature on the payload.
> As the name indicates, micro aims to be somewhat of a successor to the nano editor by being easy to install and use in a pinch, but micro also aims to be enjoyable to use full time, whether you work in the terminal because you prefer it (like me), or because you need to (over ssh).
Personally, as someone who uses nano a fair bit, this really doesn’t hit many of the reasons why I use it in the first place. It’s much less “standard” and depends on a language that is not readily available on preinstalled on many platforms (like it or not, C is everywhere and comes “for free”). I’m not seeing many additional features compared to nano, either. And a bit of a personal preference: nano’s keybindings sorta match readline/Emacs/Cocoa, so it works a lot better with my muscle memory.
Well, you don't need to install a compiler for it if your distro ships it (and there is a fully static binary that should just work right about everywhere)
I use computers I can’t install a Go toolchain fairly often, either because I don’t have permission to do so or
Go isn’t really supported for the platform.
I sometimes need to do work on niche and/or cursed platforms: iPhone, Linux 2.something for MIPS, a semi-functional Linux reimplementation, … Finding a Go toolchain for these is not easy, if it exists at all, but one for C with the right set of libraries (as far as I am aware, just ncurses?) if it didn't already ship with the OS or was available in some prebuilt form is not nearly as hard.
If you're missing a particular platform and it's even remotely popular, open an issue. Ideally if you can open a PR for it too that'd be great, but those kinds of requests are usually easy to satisfy but won't be done until there's demand for them.
I don't hate the software, I'm merely listing reasons why I don't think I could use this over nano; a list I think is relevant because the project seems to have an explicit goal of being competitive with it. I am well aware that Go is a compiled language, the issue I have is that its reach is less than C's. (FWIW, the "list" I was referring to was the list of precompiled binaries, not the feature list, which I pulled from the website copy.)
I must admit that I did a double take since I'm so used to seeing projects that only release for Windows and OSX but not Linux, or some other combination of two out of those three, but I suppose that is me having too low expectation more than anything else.
You could open an issue asking for the platform you are missing- Go supposedly has good cross compilation support[0], so as long as Go supports it and you can help confirm that the builds work for the devs they might be open to it.
I usually build from source for three different platforms (phone, regular pc, arm) on my main computer, and carry around the binaries with my dotfiles. Building from source consists of a single go get command, so it's not too bad. And I've yet to hit a single compatability issue with thos ebinaries, knock on wood.
Go has excellent support for cross-platform compilation. You could even set up a repo with CI to build the tools you want (since I presume you don't trust binaries) for many platforms. You could build it within a Docker container locally if cloud is not your taste.
I don't think that being able to build your editor is required on any platform. And a C toolchain might be "everywhere", but it's not on a default Alpine linux, the foundation for many containers. Maybe the future distros will look more like Project Atomic, Rancher, etc. anyway.
Micro is excellent as a git commit editor. You don't have to leave your terminal, and you have full mouse support if you want to go back and change something.
Looks nice. Being able to use the mouse to select and navigate text is huge for new and old terminal users. Theres a huge gap between nano and vim, and this is a good fit. Good defaults are important for first impressions and keeping users, and micro seems to be fully aware of that.
Excellent. Exactly what I wanted: a small static editor that I can leave in my home dir and use in any weird docker image or small server. Common commands like ctrl-s to save, and no modes.
Have aliased micro to `mi`, so I don't have any excuse to use vi / nano over it.
And frankly, it's just works — syntax highlighting, intuitive shortcuts, good input controls.
Those two tools seem very different, I'm not sure what a combination of them would be. Would it be a modal editor? Would it support the shell functionality vim has? Would it allow plugins? It's like asking about the perfect combination of a bike and a plane.
Serious question, btw. I'm genuinely curious what you think a combination would look like.
I'll take a crack at it. It would be vim under the hood but big changes to the defaults in favor of first time users over experienced users to allow using it for basic features wihout knowing ANY of the eccentricities or history of terminal based editors or even modal editors. As a starting point, think evim defaults which smothly allow you into regualr vim when you are ready or feel like it.
Vim does things that I can't imagine many other editors doing, and the pletora of less obvious features like editing over ssh, vimdiff, TOhtml, print to PS, etc are just lovely.
Many would never learn those features at all, and power uers would be less likely to develop, but that seems like a starting point.
As a bonus for all you experienced vimmers, if you want to feel the real excitement of learning how to use an untuitive new tool, like back when you were green, open up easy vim in a terminal.
That makes sense to me. I only picked up vim a couple years ago and just bit the bullet and bought Practical Vim because I was drowning. Easier defaults, or a 'beginner mode' seem like a perfectly reasonable evolution.
Despite the sassy response in the FAQ about Vim keybindings, I am planning to implement Vim keybindings for micro in the next version, along with an improvement to the keybinding system in general. Stay tuned for 2.1.0 which I hope will include this feature.
Mostly so that I can use Vim keybindings with micro :). Hopefully after improving the keybinding system, it will be fairly easy to implement a Vim plugin, so it shouldn't take much time. Of course, the Vim plugin will be optional and not provided by default, but I think it would be nice to have, and would make me more efficient with micro.
I use 'vanilla' vim on my servers, and I dislike the defaults enough that it bothers me, but not enough that I've ever gone through the effort of setting things up.
Micro would be perfect in my situation, because I'd get something nice out of the box and still be able to use my vim bindings :).
Seriously, though. I do like the simplicity and the overall approach, support for the mouse, and so on. I would use this. But I don't know if I can give up mode based editing... need to delete 3 lines? d3d. Search with /string. Get the next result with n. It's just so much faster than learning a million modifier keys. Maybe there's room for something in between this and Vim?
It depends what you call the "home row" and where you keep your fingers.
If you expect to use these shortcuts (typically with the outer fingers of your hands) your hands will rest at a slightly higher position in your keyboard, with the pinkies near Esc and Del, and the thumbs near the spacebar. (Other fingers over the letters.)
I guess it depends on what you've trained yourself to do.
I don't think I've seen anyone with their fingers stretched out or diagonal like that as a 'home row' position, though. It makes much more sense to 'default' to having your hands somewhat straight and on the keys you're likely to press more regularly (the (center) letter row).
key chords, F-keys, waiting for windows to pop up, those are all extra things that take time and get in the way. My fingers need to stay near their home on the home row.
> It's just so much faster than learning a million modifier keys.
I'm a long time vim key bound app user but this just makes me chuckle as vim users have already gone through learning million keybindings before they can be fluent with its use... not to mention the weird defaults.
Something like Amp [1] or Kakoune [2] ? As with vim they are modal, but one needs to press less keystrokes and they are more intuitive as they use object_letter -> action_letter, not action_letter -> object_letter model.
Yeah, I was joking, but honestly I'd love to use this as a nice out-of-the-box solution if it had Vim keybindings. I use Emacs with Vim keybindings on my dev machine, and VSCode for most coding, so I only really use 'proper' Vim on my servers. and I keep not finding the time to set things up properly there...
Keep in mind they refer to modern for a terminal-based editor, not editor in general. Have you used any other term-based editors? They lack most of micro's features unless you install tons of plugins and extra configuration.
Micro is more suited for people that are used to the Windows/Notepad-CUA workflow (Use Ctrl-C for copy Ctrl-V to paste, Shift-Arrow to select, etc.) and want to use that workflow inside the terminal instead of a full blown GUI application.
If you are already learned how to use vim Micro doesn't make much sense.
I'd think people used to Windows/Notepad/CUA editors would be most comfortable with the venerable Midnight Commander editor (mcedit).
The main issue is probably that Windows editors rely heavily on modifier-arrow combinations. It's quite fiddly to get them all to work correctly inside the various terminals, and there is not much that a application running inside a terminal can do about that.
"Intuitive" means knowing something without having learned it anywhere; it doesn't matter where you come from.
There used to be a very popular, though shamefully ignorant phrase going around decades ago that "the only intuitive interface is the nipple; all else has to be learned". Maybe people still spread this, but I haven't heard it in a very, very long time. Whoever came up with it clearly didn't know about the latching difficulties that newborns can have, and how we have full blown breastfeeding clinics to help moms.
Features that require plugins in sublime also come standard and are incredibly useful, like using it as part of a pipeline or my single favorite editor feature of textfilters, like the sublime filterpipes plugin. Meaning if I know how to do something using a regular cli tool, you just do that without having to do it in some new way. For me that means I can use Micro as an interactive front end for xsv for giant csv files of questionable provenance which require some hand fixing as well as some large scale transformation.
Since 2.0, the stability on enormous files has also been off the charts great. It will open and be ready to work on 1gb+ text files faster than wc can tell you how long they are.
Anyway, as you may have noticed, I am an enormous micro fanboy, sorry not sorry.