Modern terminal-based text editor
micro-editor.github.io
micro-editor.github.io
I wouldn't call it critical, but it really speeds up the learning process, or for users thst only use the program once in a blue moon (because GUI)
I like it a lot; I wouldn't be sorry to see it take off and get included in OS X, major linux distros, etc. Because right now if you don't want to use vi/vim, your only reliably available option is nano, and nano is a terrible editor.
micro on the other hand feels a lot more like Sublime Text for the terminal. I like it. :)
This one, micro, looks interesting. I’ll give it a try.
Remembered why I didn’t stick with it now, it doesn’t have menus and there was a bug that has been fixed, will try again.
The TUI of MsDos Edit and Turbo Vision (for example, Turbo Pascal or Turbo C main editors) were extremely intuitive to use.
I always wonder why they had no real successors in recent times.
- You can add `mouse:off` to your config to disable the mouse
- I use `cursorline:off` to help on slower connections. This prevents having to redraw an entire line when the cursor moves up or down.
Feel free to open issues for anything that can be improved if you haven't already.
I came across LE[0] the other day. Played around with it a bit - not bad[1]. It could end up being my replacement "simple" editor. Lots of nice additional features too (binary, hex, line drawings, colors, etc).
Project seems dead since 2014 (based on Wikipedia) but there's a github page[2] setup for it.
[0] https://en.wikipedia.org/wiki/LE_(text_editor)
EDIT: why the downvote? Not trolling, just genuinely sad that with today's hard drive sizes it's not a given that Emacs is available virtually everywhere, like vi or nano are.
A modern, straightforward CLI editor would help many people.
Isn't that what a true beginner would use anyway instead of the terminal version?
Which is still nearly useless without knowing of lots of Emacs arcana.
I know you can activate those keybinding in Emacs, but then none of the documentation you find about keyboard shortcuts will apply to you.
The fact that many places support emacs keybindings (like MATLAB or IntelliJ) are an indication of how many programmers are used to those keybindings, but beginning or aspiring users most certainly are not.
Don't get me wrong. I love Emacs. I use Emacs everywhere, and for everything. But I know that the default behaviour and keybindings were a hurdle to overcome when I first got to know Emacs, and it took me time and effort to get comfortable within the editor.
But yes, it takes a time to get used to. But that's matter of familiarity.
https://gist.github.com/cben/ada7675ab9aa14000a1a50eae398611...
-- emacs user for >15yr, tired of motor context switching. (Terminal Ctrl+Shift+X/C/V vs it opening devtools in Chrome is bad enough...)
I would suggest it is easy to use, mainly because it can be customised pretty heavily to work your way, it just isn't easy to learn which is why I've stuck with other options.
It's not actually hard to learn. I reckon vi is harder to learn, but at least with vi you know you have to do things differently. Emacs is much closer to other common editors, just a little bit different, and that can make it surprisingly frustrating, with the emphasis on surprise.
Because MB don't matter. It's about the experience it offers (e.g. as a better nano for early users) or doesn't offer.
Nobody cares if Emacs is only 3MB more -- it's not an argument for "just use Emacs then".
I beg your pardon, but since Linux is increasingly used nowadays in quite resource constrained embedded devices, MB definitely does matter. (No, I don't claim that the individual 10 MB is very much on most devices that are actually capable of running linux. But once you go down that road and start having something else bloated than just the text editor, you are a few hundred MBs poorer in no time, and that is a lot.)
https://blog.filippo.io/shrink-your-go-binaries-with-this-on...
How are those relevant in our context?
Most of those "constrained embedded devices" (from smartphones to IoT and set top boxes) don't run terminals and editors anyway. And those that do belong to a niche, and those people can install whatever they want, be it nano, micro or whatever fits.
If you're concerned about the programmers of those "constrained embedded devices", that might want to ssh and edit something on them, then those programmers don't use nano anyway, so this doesn't concern them either.
Nano really gets the job done for people who have no clue about editor usage. If you only need to edit a few lines in a file once a month, immediate accessibility Nano provides is more valuable than powerful features that take time to memorize and absorb into muscle memory.
Emacs, Vim are for people who use Nano enough to start feeling uncomfortable.
Vim lists `:q' and `:help' prominently in the middle of the screen when you first start it. If you try to exit with C-c (in Normal mode), or C-c C-c (in Insert), you get this message:
"Type :quit<Enter> to exit Vim"
Only when you start it by itself intentionally, not when you want to edit something and your $EDITOR is not set, then you end up in vim without an idea, how to quit.
I remember (in the mid-90s) making another telnet session and killing vi. Swearing in the process. Yes, I later learned the :q! command.
I don't have any objection to packaging emacs with the OS. Actually, it comes with macOS, although without graphical support (/usr/bin/emacs).
The problem is that some of these servers are already stripped down - it's even worse as we're moving to containers.
Emacs, even the non-gui version, still requires about a dozen dependencies, at least on most Debian and RHEL based servers. And each time I install it, I get some bad feeling in the back of my mind, wondering if I'm the one who opened a big hole into our infrastructure because I just wouldn't learn vim. :)
And yes I know about Tramp mode from my local machine, and other tricks, but sometimes it's easier to just install the damn editor locally.
But please, instead of screaming upon being hit with that bright blue background, run mc, press F9, go to General > Appearance and select the dark or darkfar theme :) (and F10 to save config and exit)
Having said that, it breaks my heart a little to see nano bashed like that. (those of you who upvoted parent, I'm looking at you too!)
nano is 1) designed to be the best editor for slow connections, 2) Its source code is also quite easy to instrument. Eg. if you need a nano that is able to edit just a single file, someone familiar with application programming in C on linux can do it in no time.
Yes, this might be nonstandard for textmode in unix, but it will match all my GUI apps much better - and like most people I use a mix.
http://www.principiaprogramatica.com/wp-content/uploads/2009...
You'd need a very massive overhaul to introduce unicode and more than 4bit/4bit color pairs to Free Vision.
Adding to the pile of anecdata: I wish this every time I forget that our vagrants spin up without `EDITOR` or `VISUAL` configured which means I get nano for my first edit and, frankly, fuck that noise.
If you need to add a comma you forgot to a json file, nano is faster.
Nano, as other comments have stated, shows the essential keybindings at the bottom of the screen, always.
(I've been using vim for over a decade.)
I can tell you from my experience that after spending a fair amount of time to learn vi, I gave up.
Not everyone has the same mental models as you do. Having a separate input and beep mode was something my brain never internalized. Using it was always painfully slow as switching modes never became automatic for me.
(I get "no dependencies", but that seems orthogonal to being written in C. Specifically, what does C bring that isn't minimal dependencies, or a small binary?)
ExcelsiorJET, JamaicaVM, Aonix PERC, IBM Websphere Real Time, Xamarin on iOS, .NET Native, Bartok.
In the context of nano and editors, you also have to contend with POSIX, tty I/O, etc.
This matters more for distros and OSes where building things from source - either everything, as in e.g. Gentoo, or at least the base system, as in the BSDs - is pretty common and expected.
the C standard library?
I'd love a working replacement for Sublime Text written in Go rather than all of these Electron based editors. Lime Text is kind of alpha quality.
Coincidentally, code written in C doesn't have that problem.
Stability is guaranteed on userspace API level - e.g. libc. So well-behaving apps are supposed to just use that, and let it handle syscalls. But Go doesn't.
The system libraries like libc themselves use syscalls internally, yes. But on those platforms I'm talking about, they're maintained by the same people who maintain the kernel, and both components are versioned together. So they can go and change a syscall, and then also make the corresponding change to libc (without changing the latter's public ABI), and ship the updated versions together as the new OS release. Well-behaved apps dynamically link against libc, so the change is completely transparent to them.
On Linux, different people maintain the kernel and libc (and, in fact, there's no single officially blessed libc - this is one case where the old adage that "Linux is just a kernel" is in full force). Consequently, the interface between the two has to be treated as a public API, with stability guarantees.
The advantage for whom? Surely not the user.
(True story - A5000 with RISCOS back in about 1993)
(Zap wins, of course!)
I think that's the point. Seeing as nano replaced pico, and micro seems aimed at replacing nano. Also putting the SI prefixes in order of increasing size goes:
pico => nano => micro
> 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).
Learn about sshfs! Use your preferred editor (or any program) locally for files you have ssh access to. It's not the right solution for everything, but for me it is for most things.
:e scp://user@remote.tld/path/to/file
C-x C-f /scp:user@remote.tld:/path/to/file
On the one hand, this comment is brilliant, because it's a concise piece of esoteric information. High signal-to-noise! And even though I won't remember the details, I suspect that next time I have a use for this information, I'll remember enough to google it.
On the other hand, if vi or emacs is the editor you want to use, you're almost certainly not the person who chooses their editor based on trying to figure out the least painful editor that'll work over SSH and will now be relieved to use micro (rather than one of those annoying options that's already there).
Though maybe that was the joke. In which case, ya got me. Zing!
As would any other way of doing that over the network, even using a more optimized network filesystem like samba or nfs would only be slightly better.
The sweet spot is using your favorite editor with all the plugins seamlessly (I prefer it to remote access plugins or builtins) or any other similar "I need to view/edit these files" use case.
Installing Vim will be as easy as installing this, despite the "it's just a binary" blurb. I never install text editors without a package manager, or any program for that matter, so why would this 'feature' make a noticeable difference?
If the answer is then "good defaults built-in' such as col;or schemes, etc. I could see some utility there... especially to pop open a quick editor on my girlfriends or family members machine when I'm asked to fix something.
But then I already install (the wonderful) SpaceVim [1] on all my machines which solves this problem far more powerfully, with great defaults.
Note: I don't mean to be harsh or dismissive like many HN comments, these are honest questions from a real world use-case perspective. It's possible in the long-term it could overtake nano, I'm merely questioning it from a short term viewpoint.
Being written in Go, I don't see this as likely.
Text-based console editors I think are fundamentally unintuitive and make you learn a lot of different bizarre keystrokes that don't really map onto easy mnemonics or have much actual meaning, so I do kinda wonder if one set is better/worse than another.
Ok after reading that one sentence I just closed the page. Why would I want an editor whose number one feature is "easy to install"? Like any other editor is hard to install by the way.
Any new text editor isn't going to have the benefit - Vi has a 40 year headstart. Making it easy to run it standalone, without needing loads of dependencies (and therefore without needing to be in a package manager) makes it a much more useful tool. I could just SCP it across into my home directory and run it to do my work.
I seriously did not ever login into a system that does not had vim installed, excluding windows obviously, but how many of us have windows servers to manage..
Judging for yourself is one thing, making a public statement is another.
Most folks who use Vim/Emacs seem loyal to their editor and are not in much need of alternatives. Those who don't have plenty of graphical ones—Sublime, VS, Atom.
I've never expected nor done any work to attract users other than myself, so there are a handful of rough edges I've never bothered to polish, but I have in fact been using this thing full-time for several years.
Perhaps I wouldn't have written it if micro had existed back then.
It's funny how life works. There is nothing especially sophisticated about this bit of code, it has many little bugs I've never bothered to fix, and I'd design it completely differently if I started now. Still, though: after thirty-plus years writing code, I've gotten more actual use out of this little tool than anything else I've ever written. Judging by the ratio of hours spent writing it to hours spent using it, nothing else even comes close, not within an order of magnitude.
Maybe actually instead of caps-lock.
I think I've solved all my keyboard related problems know.
LOL. My experience with an average of 5-6 backgrounded vims *per each named tmux session" which I use to keep track of different source files I'm working on goes against this. Sure, I can use vim's windows, but I don't want split screen usually (I'll use the other terminal I have open if I do). I don't use tmux's windows either really. It's more a way to preserve session when changing workstations (these are remote terminals), and preserve against network drops. I use each tmux session as a contained work environment for the most part. I do all my software development using vim on a remote server, and have for most of the last two decades. I've worked with numerous other developers that work similarly for professional projects, personal projects, or both.
Let's just say that there might be people that use the combined features of terminal applications, terminals, and remote connections in ways that you might think were rare, but actually have large following and leave it at that. :)
There are benefits to being comfortable in a somewhat stock Vin, and there are benefits to having it highly customized. I find the benefits imparted might be outweighed by the discomfort when it's not as you expect if your work flow forces that situation on you, so as my work flow has changed with the type of work I do, I've tried adopting different vim strategies.
But in the end it's not about whether it's efficient, it's about whether it's rare, and I think it's not from the different vim users I've encountered, which may be an entirely different subset than the ones you have.
I tried to move to Atom, because I've heard good things, I read you could extend it in JS and that sounded good to me. The difference between customizing Emacs and customizing Atom could not be more night and day in my experience. Emacs is like a living thing, as crazy as that sounds. I feel the urge to make a slight customization to a key (which happens often) I just ask Emacs what function the key is executing and either wrap it in a custom function, or advise the function. I usually write and eval these customizations in the scratch buffer.
Meanwhile, Atom makes me restart to get any changes detected. There wasn't any live documentation system that I could find (which is something I can't fathom not having now).
Emacs, in terms of customization, is simply light years ahead of absolutely everything else. It's absurd to me that we're still stuck with it because seemingly nobody who wants to make a text editor has learned the lessons it has.
Emacs doesn't play super well with others. You can do a lot of things in emacs, but you can't do emacs in other things.
On the occasions that I'm writing Java, I find IntelliJ to be super awesome. But I get annoyed because the editor in IntelliJ is not emacs. I'd like to be able to do things I can do in emacs in IntelliJ. Realistically, that means replacing the IntelliJ editor with emacs, but at the moment that isn't really possible.
Some things you can use emacs for, like editing web forms (I used to do that with an extension in Firefox), but emacs is really not so great at being used in other programs.
As far as emacs itself, the somewhat crappy GUI rendering precludes creating an IntelliJ like experience.
Instead, everyone almost always finds their own way of rendering the text editor portion of what they are doing. Consider, your concern could just as easily be shifted to complaining about IntelliJ. Why can't I easily call out to it to get the information it knows?
And this is largely up to each person. I personally loathe the IDEA GUI. And most any GUI. I will grant that they do better screenshots, but I will take what is effectively a super powerful terminal buffer any day.
It doesn't change your point at all, but I simply have a different opinion and was asked about it. I don't really care about embedding intellij, I just want to use emacs in other things.
I do feel it is a rather personal choice. As I said, I don't care for the IDEA GUI, but I understand others do.
Vim is very powerful so although it hasn’t got features like visual blocks, you can do pretty much the same thing with macros and shortcuts - as long as you know and remember them, but that’s the tricky part... Somethings it would be nice just to click a menu to find that feature you use one a month.
I tried switching to Atom but then got lost and felt it was no way near as powerful as Vim out the box (even with the Vim plugin), so here I am stuck with Vim :-)
Vim has visual blocks? Ctrl-v. Did you mean multiple cursors?
If you're writing an editor and want to include a special feature, please consider an online help system that
-- allows you to view help about the mode and keyboard settings immediately by one keypress - with absolutely zero delay, at any time and ideally fullscreen - and return to exactly where you were before you looked up the documentation
-- optionally shows you continuous online help during your editing (like e.g. the contextually most important keybindings while you're editing)
"My fingers cannot be retrained."
I filled an issue regarding that but the maintainer seems absent.
* The IDE can be too slow to start.
* Maybe it's not working today.
* Maybe it's not on the server.
Vim addresses nearly all the requirements -- it's reliable; it's easy to use as $EDITOR, to be called by other CLI tools; and it offers great syntax coloring and editing options. It's just that it's too confusing. The old joke about developers shutting off the computer to quit...
I'm not sure whether I am happy or sad that it does that now.
Terminals have been slowly improving. Bracketed paste is now universal (I pushed this into xterm). Micro is using shift-arrow for selection. JOE uses Ctrl-Arrow, because when it was implemented, Shift-Arrow did nothing on most terminal emulators.
So here's an example (pet peeve): in Micro (and JOE with mouse mode enabled), you can select text while holding the mouse key down. If you move the mouse out of the frame, it should autoscroll to keep selecting more text. Unfortunately terminal emulators send no codes when you move out of the frame. (I submitted a patch to fix this for xterm, but still not in...)
and as for moving the state of terminals forward:
https://github.com/kovidgoyal/kitty/blob/master/protocol-ext...
It's not Emacs (although it is powerful) and will probably never be (even more so to a lisper) since it doesn't try to. But it is easy and minimal, which gives me some pause after long Emacs hours.
I was very impressed to find that it has some degree of integration with tmux and with ranger, both tools that I love, to do window splitting and file management respectively. So clever and such a strong setup for a newcomer!
I don't really feel it as a competitor and I still do work in Emacs, but it became my default terminal editor and my fallback $EDITOR. Knowing vim made things a lot easier and everything that I discover about it feels like an improvement. Highly recommended.
if err != nil && !strings.HasPrefix(err.Error(), "function does not exist")
Edit: add the missing "don't" before "provide symbols".
In Go error is an interface type that is expected to implement the `Error() string {}` method. That makes it quite trivial to implement a ErrFunctionDoesNotExist type which wraps the native "error" types returned by the lower down functions, and compare against it with a type assertion.
Doing this a lot gets really old, however so maybe the author took a shortcut. If that's the case, at least it's greppable.
For what it's worth there's a technique in use throughout the Go stdlib which embues the `error` type with extra methods which allows you to check the specific fault with a url.Parse9), for example https://golang.org/pkg/net/url/#Error
Because their implementors don't know WTF that is.
I very much agree with the sentiment of Micro here - I'm very much of the Sublime/Atom ilk, but I also love living in tmux and my editor taking up minimal resources. So in the same way that you can introduce `vim-mode` into browsers (a la Vimium), you can introduce conventional `non-vim-mode` into Vim. Vim already has so much support for plugins, perhaps unprecedently so, then we can take advantage of that without creating a whole new editor.
(sorry for being so negative; this page really could benefit from a demo video)
It's an ok editor to throw in the face of an unsuspecting random person, much better than both vi and emacs. But it's an absolutely horrible choice for constant usage.
It's also been mentioned a few times here on hn.
https://news.ycombinator.com/item?id=12388654
https://news.ycombinator.com/item?id=14427473
https://news.ycombinator.com/item?id=13735395
https://news.ycombinator.com/item?id=13636239
The only reason for me to switch to a different editor is if a majority of the systems I use have it preinstalled. Which means barebones vi/vim is still my best bet. My personal .vimrc is modified for my daily workflow, but doesn't stray too far away from barebones vim so that I always feel "at home" no matter which system I am on.
I've tried moving away to different editors, but find myself comign back to vim fairly quickly just because it is available everywhere!
micro
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[edit]
... nevermind, apparently snap just commonly does this with everything, great first experience with snap, back to apt.
Remember the keybindings is anoyning when you use several tools, or when you are triying to fix something and now need to look at the help to remember what to do. That is the most infurating thing about vim (ie: How the hell I close this stupid thing!)
Just a recommendation, csvlint, which is another Golang tool also is very useful.
I know it's the main feature that bothers me.
I also wonder if you can have all highlighting features an editor like ST3 has.
> Micro's keybindings are what you would expect from a simple-to-use editor.
Formed one idea.
then,
from the FAQ:
> Does micro support Vi keybindings?
> No, if you want to use Vim then use Vim.
Well then.
>terminal-based
Such a funny oxymoron.
I'm not really familiar with it since I'm not big on the mouse but I believe it all comes from the GPM (general purpose mouse) server, at least that is what ncurses mouse support is based on.
>>easy to install (it's just a static binary with no dependencies)
For some definition of "install". No deb/rpm/snap
If you're on macOS, the latest version can be installed via brew.
If you are on another computer and want to use it, just download a single file and run it, no need for root.
Otherwise, your package manager'll probably have it, I know that Homebrew does as well as the AUR.
> 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 https://micro-editor.github.io/about.html
It it pretty neat. Congrats to the author :+1:
It's like complaining on a site oriented towards construction workers to stop comparing something to pro-grade tools and just bask in the wonder of someone making a slightly better Craftsman ratchet. Cute idea and maybe worthwhile, but not especially relevant to professionals.
I'm very glad it was posted here.
lmao get over yourself
If you're interested at all in Unix history, if recommend playing around with it some. It can be surprising how much ed shows its influence on conventions and standards to this day.
https://www.bell-labs.com/usr/dmr/www/qed.html
I do ocassionally end up in ex mode if I need to run a few vim commands back to back. I'm curious if there are other reasons to use it though.
No, if you want to use Vim then use Vim."
Kthnksbye
The old editors are both powerful and arcane.