As a Windows native, for years I felt limited when shelling into Linux systems, because all editors felt weird to me. Obviously the solution would be "just learn vim already" but I'm lazy. I settled on nano because it at least shows what shortcuts are available, saving me from having to Google "how to find text in vim" every time. But its shortcuts are weird (to me) and even the descriptions are. UnCut? WhereIs? Huh?
Micro really got the UX right for people like me and it made me more happy than I expected. It's now the EDITOR on just about every non-GUI system I have access to and I love it.
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.
Btw fwiw I fully agree with you. I really like Windows as a desktop OS (or, more accurately, I dislike it the least), but the idea of using a GUI based server is just super weird to me.
Even pre micro I preferred Linux for servers, for this reason primarily. I understand Linux way less well than Windows but I navigated down that insane ISS config panel once, a decade ago, and decided that once was enough :-)
Given Windows' low popularity as a server OS these days it seems to me that plenty devs-who-use-Windows have a similar opinion.
As someone who grew up on Windows machines and got a MacBook Pro in high school, using Windows is extremely painful, and I built many PCs in my gaming phase. In my experience, macOS has been blatantly superior in every way. I found plenty of Arch flavors that I like much better as well.
I’m curious, why is Windows your favorite desktop OS?
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.
Eh, I wouldn't even call it that. I consider it to be similar to git: you can do some incredible things with it, and people who know how to use it can do so effectively, but there is a lot of room for improvement.
For those add-ons, don't you have to provide them with the prompts? You still need to actively _know_ how to do something to have it provide you with information.
You can use something like LunarVim which has everything already setup.
Absolutely agree that it's not a user-friendly text editor. It _does_ increase productivity when you're proficient. TBH being proficient took me a lot of time, mostly fueled by wanting to be cool in my first job (it failed), all in all I'm not entirely convinced it's a good investment.
But being able to edit using Vim at all is very very useful to edit files on servers, which happens very often in various situations.
I will 100% agree that neither emacs nor vim are "beginner-friendly", I would hesitate to call them "not user-friendly", they're just very particular about what users they're friendly with.
> 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).
For anyone that wants this: these kinds of plugins are usually called "which key" after the Emacs mode. Most of the Emacs distros ship with which-key by default and it works very well with evil.
I get the sense that they're less popular on the Vim end, though I'm not sure why.
> 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
You might be interested in the Kakoune editor. Despite being superficiality similar it's not Vim compatible, which may make it a nonstarter, and it has its own flaws that keep me from using it, but it makes a point of showing on-screen help for almost every command as you're typing.
Anything not CUA compatible feels aged... unfortunately, the standard "terminal" keyboard support is very poor regarding this things (escape key is often broken, modifier keys often compose well at all). What is really needed is a new terminal standard to support this.
The (probably not workable) alternative is to deprecate the whole thing and make a higher level protocol.
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.
Not a server distro, but it still surprised me, since I'm used that pretty much all of the distros I use have nano. ChromeOS Linux (container?) doesn't have nano, from what I can tell it only has Vim, on the topic of Vim, using J to go down was (and is) quite confusing, probably because I feel like Up should be before Down...
> 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.
I think most "hardcore" vim users do re-map Esc for something else, like Ctrl-C (or maybe it's a built-in alternative keybinding) or Caps Lock.
I've used vim for 25+ years, but always alongside other editors (only used it as my main driver for 4-5 years sometime in the 90s), so I've always stuck with Esc (which, is the default anyway).
That said, I wanna jump back on with Nvim 5.0 when I get the chance to have a free day to setup and configure it to my liking.
I did it the other way around putting Esc on CapsLock for the whole system. But yes, Esc is a pretty horrible key to reach for, especially considering how often it is used when interacting with vim.
Is it? It could be as far as line-oriented text editors are concerned, but when it comes to screen-oriented text editors, I think it is vi. vi was a step up from ed (because it was not line-oriented but screen-oriented!). Initial release of vi was 45 years ago. :)
Oh and for the curious:
> The name "vi" is derived from the shortest unambiguous abbreviation for the ex command visual, which switches the ex line editor to visual mode. The name is pronounced /ˌviːˈaɪ/ (the English letters v and i).
We need to stop getting people comfortable with the idea of just curling random stuff into their shell.
Even worse is software that suggests you sudo curl it into bash. What could possibly go wrong?
Download and build it yourself. Or download and install a packaged .deb or .rpm or whatever is the equivalent for your platform.
Do not just blindly curl into your shell things coming from people you don't know and trust to the level that they are personal friends and you would loan them your house keys or your car.
a .deb at least went through some cursory level of examination by the people who downloaded the source, built it and are authorized by the debian project to submit new .deb files to the debian package servers.
not just any random person can submit a .deb and have it go live on the gpg-key authenticated debian mirrors.
I agree that debs that were audited and distributed in the package manager are better in that way. I guess my objection is that "curl https://getmic.ro | bash" often gets a hostile reaction here on HN whereas "wget https://github.com/zyedidia/micro/releases/download/v2.0.10/... && dpkg -i micro-2.0.10-amd64.deb" does not.
The latter absolutely should get just as hostile a reaction. The only thing it provides you over the former is that it at least guarantees you that the author went to the trouble of creating a deb.
Actually, it should probably get even more hostile a reaction, since installing it that way usually means you won't get any updates for it. If you absolutely must install software from a (trusted) source other than your distribution, adding a source and then using `apt` is the way to go.
If you need to install from the author's site, that means that there is no Deb available in the official repos, or that it's outdated. In both cases, you end up installing something that the author compiled.
The reality is you need to install a random PPA or download a random deb from the author's website, github, etc. because the debian release is woefully out of date. So you're back to installing random binaries again.
If you need the latest available versions of the software you use, you should probably use a distribution that has that as a goal. Debian is built with the intention of providing stability, under the assumption that most of its users can afford to go a couple of years without feature updates in the software they use.
It is more about streamlined process of package management to which Linux users are used. At least with deb/rpm package I understand where package stuff goes and how to uninstall it (of course, packager could mess up this with arbitrary install scripts).
And each 'curl https://' packager has its own idea where his software should be installed. And many of them are not even providing automated way to delete their application.
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.
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.
For a couple of decades, my go-to terminal-based editor has been JOE (Joe's Own Editor). [1]
JOE has everything I need — it's fast, it has syntax highlighting, multiple buffers, etc. Also, it uses the WordStar key bindings, which are the same bindings used by Turbo Pascal and the other Borland IDEs that I grew up with.
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 tried Micro on for size for a few months earlier this year. I like it a lot, but stopped using it over time. Any time I reach for a text editor I kind of muscle memory open vim if it's something quick or VS code if it's a larger project.
Micro is like nano re-built for the 2020's. It feels really natural to use with sane key bindings and text selection. I like that it's written in Go and has a nice plugin framework. I might have used it more if a file manager / code tree off to the side was a built-in feature. I found a plugin that could do it, but I had some hassles with it iirc - https://github.com/NicolaiSoeborg/filemanager-plugin
Ah ok. The usual editor wars. There's one point that has to be made: software lives or dies (or withers on the vine) due to network effects. In the case of Micro vs Vim vs Emacs it's all about keybindings and the time to learn them. Micro uses CUA [0] keybindings intuitive for most Windows users, while Vim and Emacs (cua-mode notwithstanding) are stuck in the middle of shallow local optima.
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.
Right. I think saying 'Vim/Emacs aren't as good as other editors because they're unapproachable to new learners' is like saying 'Linux is a worse OS than Windows because it's hard to use'. -- Sure, you want something to be accessible to everyone. But there's also a benefit to enabling power-users to learn the system.
That said, kakoune looks like an interesting demonstration that maybe vim's <action><text selection> commands could be clearer as <text selection><action>.
Absolutely---also, Emacs, Vim and GNU/Linux aren't hard to use. You just have to accept that they're not like Windows and follow the instructions on the screen. The documentation is generally very well written and exists from beginner level to advanced. There are also tons of places where you can go to get help when you get stuck.
Imo the whole "hard to use" thing mostly comes from people who feel they are already expert (at something in Windows) and get frustrated when they discover that there are other paradigms in which they are still beginners. So they label their own knowledge as doxa, and anything that doesn't conform to it is labeled "unintuitive," "obscure," "dated," "hard to use" etc. The same mechanism is behind quite a few of the voices claiming GNU/Linux communities are unfriendly or abrasive (i.e. someone gets frustrated upon the discovery that not everyone recognizes them as the expert they think they are).
Windows sys admin here. Micro is nice because it is a single-file, stand-alone executable that has mouse support, macro record/playback and syntax highlighting. (I haven't checked Nano recently).
Because of this, I don't mind installing it on servers. It is great for making quick edits to json configs, batch files, powershell, python scripts, etc. Syntax highlighting and line numbering are key. The alternative is editing the file locally and then getting it onto the server which can be challenging for locked down systems, especially Windows Server Core which does not have a GUI environment.
Even on my local machine, if I need to make a really quick edit, it is much faster to use this than waiting for VS Code or PyCharm to load. You also stay focused. By this I mean, your eyes don't leave the powershell window that you are currently working in. This allows me to more quickly complete the task at hand.
As another commenter noted, this is a good alternative to Nano (I too need to learn Vim). I've checked this out, and I like what I see so far.
Typically my main use for text editors is for log analysis (mainly Sublime Text). This usually means I write a lot of regex for searching.
With that in mind, I do see one shortcoming in the choice of Lua as a scripting language. It's not really known for it's text processing abilities. One major shortcoming is that it doesn't have a true regex engine. This is something I use extensively.
For most of my use cases, this would require I hack together a native search in the application, and then pipe the buffer to Lua for post-processing. I'm not sure if search/replace pipelines are going to be easy to code in this manner or efficient enough to be worth it.
I use Sublime Text because it uses Python and makes this relatively easy. Or if I'm searching over thousands of logs to use ripgrep and just pipe in whatever that way since it can search 10GB in a few seconds with moderate sized regex.
Otherwise, I like the approach and the helpful commands for the user! It is definitely nice to be able to stay in a terminal instead of using a GUI to edit.
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)
I was about to post about lnav too. It's phenomenal -- and not just for logfiles! With embedded sqlite, it really is a mini ETL powertool with all the benefits of *nix-y CLI usage and scriptabity.
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.
That’s what I have never understood - why would you want to open a log file in a text editor (when the standard tools of the trade in this case should be an “unbuffered” text viewer, which by design, can handle files of any size, fgrep, and, if you want to generate a report, a stream editor, such as sed).
Exactly. Log files are viewed in a pager, not an editor.
While tools like lnav look great, many of its features can be replicated by combining smaller, purpose built tools, i.e. the core Unix philosophy.
Single log view: cat | less
Filters: rg | less
Decompression: zless, zgrep, rg -z
Timeline view: admittedly tricky, but doable with some incantation of cut, sort or reach for the big guns: awk, perl.
Live operation: not quite, but tail -f and less +F go a long way.
I've never once in almost 20 years of looking at log files thought I needed a SQL interface to them. I'm sure it's a powerful feature, but the above approach has served me well.
Definitely tough to "compete" in this space because locally most people end up going to their IDE of choice for heavier workloads and if you do decide to use a terminal editor, you'd rather have it be compatible with things you'd encounter in the wild (e.g. a remote server, someone else's machine).
That being said, this is cool. I've set it as my default editor for the GH CLI to use it for pull requests and the like, let's see how it goes!
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.
A moonlander keyboard makes for an interesting comparison here:
It's worth taking time to learn something to get a better experience. Keyboard layering takes some time to get used to (especially if you can already use a standard keyboard), but is worth being able to reduce hand movements. Modal editing takes some time to get used to, but provides a richer navigation/editing experience.
Similarly, you can customise your moonlander to the point where it's yours and no one would know how to use your keyboard.
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.
Doesn't seem to be mentioned yet but at least on my machine, it knows shellcheck is installed and as I save scripts I get red arrows at the side of "problems" and the description, for eg,
Quotes/backslashes will be treated literally. Use an array. [SC2089]
At the bottom, I find it quite useful although I'm not sure how one would turn it off as I didn't turn it on.
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.
There's more to vim keybindings and modal editing than "nav keys on home row". e.g. if the editor has the line `println("Hello |World")` where the cursor is at |, you can change the whole text inside the "" by typing `ci"`, or change the word by typing `cw`. -- QMK is great, but it can't do that.
I use Vim (and Emacs) as a Dvorak user. I don't change the layouts; I just stick with mnemonics. e.g. in vim, g is "go..", c is "change..", d is "delete..".
With Dvorak, the `jk` are adjacent, so that works out. `h` is still to the left of `l`... but, vim's keybindings are excellent at navigating in a line, so many `h`/`l` should be avoided anyway.
I think "hard to get vim to be as good a development environment as an IDE" is more/less a fair point.
Anyway, it's great that micro can fill a niche for you. I wish everyone could appreciate modal editing and symmetrical keyboards.
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.
> 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?
vim comes with a tutorial that teaches all the basics from inside vim... It's installed pretty much everywhere, you just have to run vimtutor.
> 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?
Why the condescending tone?
Yes I do code, everyday and full time, and vim absolutely increased my focus and productivity.
There is way too much to talk about in a single post, but stuff like macros, showing multiple files at once, (tabs is not the natural way of doing things in vim), viewing multiple parts of the same file at once the native integration with the terminal (just ctrl-x to go back to the terminal and fg back to vim, or execute any command with :! ) are great for productivity when you have to deal with multiple tools.
> High-level language tooling like refactoring and static analysis are way, way more important for medium+ size projects productivity.
I agree, and that's why I use vim. I can do all of that more efficiently in vim because the refactoring tools are way more powerful, and everything is macro-able.
> 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.
Condescending and even insulting tone again... great.
FYI, vim has all the features of any modern IDE. The opposite is not true however.
So I was a flippant because I was answering to this:
> The things people build to avoid learning vi...
As if learning vi was the obvious thing everybody just needs to do. Which is a common attitude within certain circles. "It was hard for me, but I made it through and so should you, with just as much pain, haha".
I was brought into the world of computers with the promise that they would help build a better world, one where the edges of technology get softer as years pass.
vi insisting on menu-less text mode and rote memorization of arcane key combinations negates any progress that was made in the last forty years in software usability. I refuse vi because I believe there _has_ to be a better way of doing things.
I am super duper keen to try out any new text editors but I can't move away from vi bindings and the vi mental model. It's done more for my productivity than anything else and I think has reduced or rather pushed back the time when I will eventually get RSI as I can effectively limit the number of key presses to get something done.
What on earth are you talking about? The whole point of all these tools is to reduce the amount of key presses needed. Why do you think ed -- the standard text editor -- was conceived? I jest but this is kind of the whole point of modern computer interfaces vs typewriters and punch cards. Historically it has _absolutely_ been a bottleneck, and I feel like it's being taken for granted that you can search-and-replace or use sed or your IDE's context-aware renaming/refactoring.
Have you even used macros in vim (or whatever)? It's practically a modern editor's raison d'être.
I would be interested to see a serious comparison between the two. This debate comes up every single time that Vim is discussed and I'm honestly not really sure where I come down on it. As a Vim user I know that editing this way _feels_ better and faster but I'm not sure how true that actually is. One thing that I can say for sure is that it has done wonders for my RSI.
I agree with the GP and I think it's actually about the type of motions you are doing. In particular, having the cursor movement tied to hjkl means I can avoid moving my hands off the home row. After developing a low stress way to type like that (true "touch typing", like playing the piano) it means that my arms, wrists and hands are all relaxed and well positioned the whole day. I used to get RSI and the only time it affects me now is when I am forced into some activity that takes me heavily out of that flow.
(part of the beauty is that vi-style motion keys or similar philosophy have promulgated into everything from browser plugins to a plethora of terminal tools like htop, ncdu, tig etc.)
I like modal editing, but mostly because you have to use keybinds less (especially awful ones that combine control + shift + alt).
Just moving your hands to the arrow keys might be less efficient, but in my experience it has got nothing to do with RSI—you’re just moving your whole hand with your shoulders. That seems about as repetitive stress-inducing as going to fetch a cup of coffee.
Of course when one plays the piano one has to move the hands by the shoulders a lot... the piano is not a stenography keyboard.
Personally I spend a lot of time staring at code thinking “wtf was this person thinking when they did this…I know there was a reason but..what was it” (doubly so if I’m the one who wrote it). So I think you’re right, unless there’s a key binding to read minds too :)
Same thing kinda goes for anything on the command line.
The amount of commands that are 2-3 characters long really slows down learning and when it comes to it you will often be typing another 80 ish characters after the command name for options and piping anyway.
It's not about the number of keystrokes, it's about the number of keystrokes pressed simultaneously - this where Vim makes a lot of difference. All that Ctrl-Alt-Shift-X stuff is what really harms hands.
I wouldn't say something lacking a LSP is modern by todays standards, as that would mean it lacks syntax highlighting, go-to definition, and other basic things for a bunch of languages.
It isn't good enough. There's a bunch of new languages coming out all the time, and even ones that are 10 years old (Clojure) aren't supported well in editors without LSP support, like Micro. LSP support allows the language ecosystem to provide the building blocks so that developers could write that in any editor that supports LSP.
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.
If you've never needed to use go-to definition then I assume you never work on anything even remotely large. But even in projects with, I don't know, 10 files, I find go-to extremely useful.
I'm a bit late to this thread, but I wanted to note: If you are using Ubuntu / Debian / Mint, don't install via "sudo apt install micro". It has been compiled wrong and it launches with a -debug flag which leaves a log.txt file behind every time it is launched. Maintainer is aware but this isn't yet resolved. [0]
Alternatives include downloading the .deb file from the Github repo and using the getmic.ro bash script. [1]
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
Very helpful response, but generally I think the set of people who refuse to learn vi/vim is orthogonal to the set of people who are willing to go seek support!
This looks nice but I can't what the target audience and intended usage patterns are. It's somewhere between
1. "simple text editor to use on servers/whenever I need to edit something quickly". That place is taken by nano that is easy enough so that people don't have to learn it, or vim for those who mastered it. In this niche it's important for the editor to be ubiquitous enough and present even on the old machines.
2. Regular day-to-day code editor. Micro has _some_ autocompletion, syntax highlighting etc. But for a modern editor to function, it really needs an LSP client implementation. But this seems to not be happening so far: https://github.com/zyedidia/micro/issues/1138
Micro has some features in each bucket (simplicity, ease of usage vs. IDE-like features) but does not seem to really excel at either.
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.
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.
> 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.
Because sometimes I can't download binaries from the internet and sometimes... well, I don't have the internet! One scenario for the latter is installing an OS from scratch.
One might call me lazy but I don't want to end up learning multiple editors for different scenarios if the benefits are marginal, especially if I can get away with just one!
Micro is my go-to git commit message editor, especially because it can correctly syntax highlight verbose-mode commit messages (passing -v to git commit will put the diff you're committing below your message as a helpful reminder).
Awesome! I keep looking for the perfect solution for this. I use GUI editors for real projects but when I need to quickly edit a config file on a remote machine I currently use mg.
It's not bad but it doesn't support Unicode. It's also nearing 35 years old now and while that has its advantages maybe something more modern would be better. The main reason I still use it is that it has emacs keybindings which sadly are seared deep into my brain.
For a while, I recommended the fte editor[1] to people coming in from the Windows/DOS camp, but that went out of development quite a long time ago. Good to have a go-to non-proselytizing replacement that works in a terminal and isn't nano.
Tangent: I noticed more and more projects advertising a single executable as a way of distributing their apps. I don't want to judge, it's just another way of doing it, but I'm curious: is this a trend and what led to it? I feel like I missed something.
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.
Slight off-topic, but I wanted to address the above concern.
APT, DNF, and many other package managers have an "autoremove" command that will uninstall unused dependencies. So if you did "apt-get -y install $PACKAGE && apt-get -y remove $PACKAGE && apt-get autoremove", you won't have any of $PACKAGE's dependencies hanging around after.
True. The scenario I was thinking of was `./configure && make && sudo make install` and iterating on all the missing dependencies that the configure script flags.
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.
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.
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.
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.
Micro really got the UX right for people like me and it made me more happy than I expected. It's now the EDITOR on just about every non-GUI system I have access to and I love it.
Thanks, Micro authors!