Micro – a modern and intuitive terminal-based text editor

Yup. Great, well balanced light editor with almost 0 installation worries. Just copy the binary over.

> Obviously the solution would be "just learn vim already" but I'm lazy.

Vim keybindings are great. :) But I'd rather people learn vim keybindings out of curiosity rather than necessity.

I started to heavily using vim since the last few months because writing code through SSH is very attractive for my current situation.

For me, learning vim is like learning an foreign language, a few hundred words (or few hotkey/:commands for vim) can get you started, but it's not easy to reach the level of native speakers, and some old rules in your language (for example, HJKL keys in vim vs the "natural" arrow keys) will interfere your progress.

Maybe I'm going to piss many people off here, but vim is not an user-friendly text editor. An user friendly editor should pop some kind of prompt when I pressed the first g/G key and show me what I could press the next, not telling me to read :help (which probably has the volume of a dictionary at this point).

Based on my 2 minutes with Micro and the information I read from it's `help defaultkeys`, the size of it's hotkeys are more healthy and manageable. So that's a plus from me.

I have the same feeling of limitation when using Windows. As someone who's used to Linux and other UNIXy systems, the idea of having and using GUI software on servers is... distasteful to me, to put it mildly. GUI configuration makes changes easy, but change management extremely difficult, which is not a good combination. Therefore I struggle with administering Windows because there is no useful editor by default when you use it remotely over the console, leading to a lot of friction to just "browsing around" on a remote Windows machine, and most of the time installing what I need is not an option due to the lack of a default, trusted package manager. (though that might be changing, finally)

While PowerShell is, well, powerful and nowadays there's at least OpenSSH for for secure and convenient remote access, unfortunately it's rarely installed and PowerShell over SSH is still very janky and even when it's there, many things assume a GUI, which is anything but convenient to me. My workflows tend to use SSH all over the place to make remote access transparent.

The mcedit (editor from midnight commander) has been my choice of editor before I switched to vim. Thanks for the micro suggestion.

> saving me from having to Google "how to find text in vim" every time

Escape, slash, and write whatever you want to find, and press enter:

  [Escape]/foo[Enter]

After a few weeks, you'll start trying to do it on every editor...

Even though it feels weird, it will still pay off to learn the very basics of vim. The reson for that is simply that its pre-installed on most environments - including servers and embedded linux devices, and available in a ssh session. On some of those environments it might not be desireable/allowed to install additional software.

Basics for me is i,a,:q,:wq just be able to edit something and get out of the editor again. Adding d,y,p,/,^,$ makes it a bit more productive.

Yes, but not just a Windows native, a DOS edit, Netware, Motif/CDE native, similar to Mac OS dialects.

IBM CUA, from mainframe terminals to OS2. Later Geany and Sublime Text, recently VSCode.

Unix was earlier so didn’t get with the program. I limped along with nano and a subset of vim for years. Noticed “ne” about ten years ago, was ok.

Micro is a godsend and in the Ubuntu repos now. Debian too? Not sure.

I thought ed is the standard text editor?

But I agree on micro. As a Linux user who refused since 20 years up until now to learn vi or emacs nano and than micro was a real pain relive.

mcedit has been a huge time saver for anyone familiar with Norton Commander.

> saving me from having to Google "how to find text in vim" every time

Why would you have to do it every time? Sure, if you do it very rarely then you may forget, but I dunno... In any case, the way you search in vim is the way you search in `less`, `mupdf`, etc.

Why is this more dangerous than installing a deb, which can also run arbitrary code as root?

Since the script comes from GitHub repo, and the source is also on the repo, isn't building the source the same as getting the shell script and running it? I mean if one is compromised, the other might be compromised too.

Literally every time somebody on HN has to write a comment shaming for curling into bash. We get it. You should download the script, inspect it, and then execute it.

I suppose using a package managers that random people can commit stuff into would be a no go for you too.

I think complaining about streamlined remote script execution is just being pedantic.

If you're so worried, wget to see and run.

This is not the same as "sudo curl https://getsomefile.ro | bash". That is dangerous. While I understand your point, it's really not the same thing. This checks your system for its architecture and then downloads the correct binary to the directory you run it from. I know this because it's very easy to copy the URL, drop it in your browser and read the script. That's what I did before running it. And it is certainly safer than adding some random software repository which is what a lot of instructions suggest.

I really appreciate that he ends the page with links to other editors to consider, in case his doesn't fit someone's needs

JOE is where I started my Unix editor journey, the Wordstar bindings were familiar coming from DOS and Borland tools. From there I went on to jed which also had Wordstar support and it gave me a taste for extensibility. Jed's native keybindings were based on Emacs though so I eventually arrived to the real deal and it has been Emacs ever since then. But also learned vi basics along the way of course. :)

I feel the same way, I use JOE's jstar mode because I fondly recall using Wordstar under CP/M, and it has enough features for basic editing.

Been using JOE in it’s jpico form for many years now.

What got me started was actually how much faster it is on a Raspberry Pi compared to nano.

Rebuilt for the 1980s IBM CUA. :-D

I'm sure Micro is great, but I doubt it's anywhere even near Vim or Emacs, in any respect. Because it's not "all about keybindings," and claiming that either of those editors is stuck in a local optimum is simply counterfactual. As for living and dying, Vim is 30 years old and Emacs is 45 years old. We'll just have to see how long Micro stays in the game.

But on the other hand a very large chunk of those who would ever consider using a non-GUI text editor come from a vi or Emacs background.

> (I too need to learn Vim)

well, then start. What are you waiting for?

E.g. here: https://danielmiessler.com/study/vim. Don't miss Vim as Language.

If you're fiddling with logs, pick an editor that can handle (theoretically) unlimited file sizes -- which is something that very few mention supporting. vim will do you great stead for what you seem to need.

Try out the Logfile Navigator (http://lnav.org) for working with logs instead of a text editor. It can provide a lot of benefits by default, like collating messages from multiple files together, syntax highlighting, decompressing files and so on.

(Sorry this is a little off topic, but there’s a lot of room for improvement for working with log files over a text editor without scaling up to a log service)

The ergonomics are so much better than vi/vim/nano that it is my go to edit from the CLI tool. Sometimes it's faster to just edit a line than mouse over to my IDE.

And yes I think vim has bad ergonomics. It's so much effort to get it configured to work for me. I get way more out of Alfred and my moonlander keyboard with macros that work across the whole OS.

It’s compatible with just about everything still maintained. And a simple scp if not installed.

At point while on the Windows kernel team, I was working on a port of edit.exe but when I left the team, development stopped. I was initially going for a identical replacement with a replica menu system but behind able to handle large files, modern capabilities.

Thankfully, the author of Yori[0] shell has made a modern port of EDIT called, well, Yedit[1].

[0]: http://www.malsmith.net/yori/

[1]: https://virtuallyfun.com/wordpress/2021/03/03/yedit-the-miss...

"If I had asked people what they wanted, they would have said faster emacs."

I love my laziness, and won't give it up. =)

I've already switched to this. Installing and configuring it was a lot easier than learning vi would have been.

I wish people would stop treating vi like it's God's gift to every programmer on earth. I forced myself to use it for two weeks just to see what the fuss is all about and try to push through any bias.

So first off I use Dvorak so I have to switch tons of the bindings so I can use reference layouts. My moonlander keyboard already gives me directional movement on home keys. I don't have a ton of things to automate that I cant do in Alfred and my keyboard has over 1000 possible slots for keys and macros, more than I could ever use. Unlike Alfred workflows, the macros are trapped in vim. I have to add a ton of plugins to get anything approaching the experience of Pycharm and now it's just as slow, the auto completion is worse, and it looks like ass. But hey at least I can use it over an ssh connection (gotta transport all of my config first!), as if sshfs is not a thing, not that my work load is all cloud containers so I rarely ssh at all anyways.

Micro fills a niche for me where I don't want to leave the terminal and just need to edit a few lines.

Let's make one thing clear. I am not avoiding learning vi, I _refuse_ learning vi.

There is no reason in 2021 for to have such terrible discoverability. If it's such a great tool, why did no one see fit making it progressively learnable from within the tool itself?

I see people talking about using vim like some other talk about going to the gym. Great abs, fast editing, but... do you even code, bro?

Unless I'm working on trivial stuff, my crafting speed is rarely limited by my editing capabilities. When it is, it's usually because the code is repetitive and it's time to change it.

High-level language tooling like refactoring and static analysis are way, way more important for medium+ size projects productivity.These are much better served by an actual IDE than some one-off integration with an obtuse editor deriving macho pride from it's 1970's TTY-limited semantics.

When has the number of key presses seriously been the bottleneck for anyone when developing software

Look I like mechanical keyboards and editor setups as well, but let's not pretend it's this great panacea. It just feels nicer.

LSP is not required for syntax highlighting, and in most languages global/ctags is good enough for jump to definition

LSP is good though

LSP is definetely not needed (or even widely used?) for syntax highlighting.

LSP is not even used for highlighing in vscode, where it originated.

I have never found the need to use go-to definition, until I started working on some golang codebases. The code organization in these codebases is typically abysmal, with multiple files in the same package participating in N ways nested orgy.

Of course, micro is written in golang, and it seems like the author is doing just fine without relying on LSP.

Just in case you weren't aware, the project is open source and hosted on GitHub, where you can also find their issue tracker, if you really want to reach the maintainers: https://github.com/zyedidia/micro/issues

1 month in after more than 10 years with nano. Can recommend it as well.

I use Micro as a better Nano. The syntax highlighting is better, the copy pasting is better, and most of all, the key bindings are the ones I'm used to. I can use Nano fine, but Micro is much more intuitive.

> In this niche it's important for the editor to be ubiquitous enough and present even on the old machines.

Why are people still treating this like a deal breaker? It's a static go binary, if I can ssh to it, I can scp micro to it, or more typically just curl the latest release from GitHub into ~/.local/bin (no sudo!). Just like you'd do with your vimrc.

Apparently this is controversial.

It runs everywhere and uses keybindings available everywhere else. It’s not an IDE. Basically can take over all simple to medium editing tasks. i.e. a no-brainer.

I use godit as my microemacs. It's written in Go so you get a statically linked executable, easy to cross-compile and it supports UTF-8.

https://github.com/nsf/godit/

mc + mcedit is much better for those, who came from DOS camp.

you can do this when the installation is presented this way

How is it different than running a binary you just downloaded?

Seems like a trend to me, enabled in part by tool chains like Go’s which make it easy. I like them because using/deploying is simple: put the file somewhere and run it. No apt get runtime library config etc etc to worry about.

if I had to guess: things like Docker, K8s, and Lambda. All of them make installing sprawling apps with tons of dependencies really troublesome at best. A single executable with almost no dependencies really simplifies that problem.

this feels like the natural evolution if container based deployment. people have gotten focused on a “single thing that works everywhere” to the point that we are back to having binaries include all dependencies instead of making it clear what the host system needs.

Single executable files are very nice because you don't need to run `apt install <14 dependencies>` to try a piece of software, you just try it and if you don't like it, you delete it without any cruft left on your system.

Go and Rust are two languages whose compilers produce statically-linked executables and they are growing in popularity, so you should expect to see more and more of these kinds of programs. And as these programs become more spread, I expect that other languages (either existing or new) will make it easier for developers to distribute their projects as single files.

Go doesn't support shared libraries. The community likes it...

“I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” – John Carmack

http://harmful.cat-v.org/software/dynamic-linking/

Just looking at the documentation nothing jumps out, but reading the plugin reference it seems like it would be an easy thing to add.

You have access to read a file, you can get the current buffer, so inserting the text must be almost trivial.

It seems like an odd showstoppper to have, but if you're tempted to switch writing the plugin might help you get a feel for how good the editor is in other ways.

Why don’t you write a script that does that?