I would suggest that, to replace nano, the #1 feature missing is: always show the most used keybindings at the bottom, just like nano does. IMHO the top feature of nano is that you don't need to remember commands and keybindings at all, the most important things you need are always reminded to you.
I have to say that is actually the main reason why I would be using nano. I know the basic commands for vim, as well as some extended keys for nano (save), but nano really helps for being able to not spend time outside of development to find keys for critical functions.
Micro does have a help option, which is haven't really read, only briefly checked out the exe a few hours ago.
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)
This looks like it's aimed at being a better nano, not a better vim.
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.
It's 10MB uncompressed so at that point I'd hope Emacs would have finally become a "reliably available option" first (13MB on my system).
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.
While emacs is a terrific editor (or platform for editors), it is not easy to use. It has a unique set of keyboard shortcuts, which means that for most newcomers, their familiar hotkeys or key combos will do things that they don't expect.
A modern, straightforward CLI editor would help many people.
Actually its default keys are available in lots of other places. Most notably anything that uses readline (like bash), but I've even found the keys work in unexpected places like the MATLAB editor. Plus the letter keys and arrow keys already do what you expect. What "expected behaviour" are you referring to?
Granted, but bash and other readline applications generally have a very different mode of operation compared to a text editor. They operate on single lines of input at a time (most of the time). Editors like emacs operate on a multi-line body of text, and most people expect those to work like the other text fields in their environment (Ctrl-C/X/V for copy/cut/past, Ctrl-A for select all, shift-home/end/arrows to select text etc.)
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 only Emacs users use those keybindings with those widgets, so that's not a good argument to say "emacs keybindings are well known by novice users".
Emacs cua-mode is not bad.
It does create some confusion with C-x shortcuts, eg. C-x C-s when typed too slowly will cut selected text and enter search, instead of saving :-(
But I'd love a more total conversion to CUA... E.g. I have C-o to open files, and C-w to close buffer/window.
We're talking terminal (not GUI) editors here. If I fire emacs on macOS there's no menu displayed by default. If I connect remotely on a Debian machine, the menu is there but mouse reporting is not working. The help, if started by itself, vanishes at the first keypress (on macOS), which makes it really easy to skip the C-x C-c part, and uses the emacs-only convention of C- instead of the well known ^ for control (although it's explained right there), thus doubly easy to miss. I can see how newcomers would be turned away from it.
`apt-get install emacs-nox` pulls in 83MB on jessie. The installed-by-default one is vim-tiny (clocking in at 27MB), not vim-nox (which pulls in an additional 21MB), for which there is no similar emacs package. Turns out nano is ~370kB, that makes for a small non-modal beginner editor, the modal one being covered by vim-tiny.
Fair, but I don't think 20MB vs 80MB should be a problem in 2017, people are downloading ~60GB games off Steam, downloading a ~5GB ISO every 6-24 months is not that much in comparison.
I was once a "true beginner", having been forced to use basic terminal commands in school and having decided to get a raspberry pi and shove Raspbian on it for laughs. There is no GUI over ssh from Windows unless you already know what you're doing. In that context, accidentally opening emacs is bewildering :)
That's basically my question. What's the market for people who want a terminal based programmers editor in late 2017 who don't already use Vim or Emacs?
I moved from Vim to Spacemacs (emacs with evil kit) four years ago. I was worried initially worried my productivity might go down due to not knowing emacs functions. Surprisingly, there was an included plugin (https://github.com/kai2nenobu/guide-key/blob/master/README.o...) that offered me all the possible keys at the bottom. Most functiond are two, three or four keys away. For instance, I wanted to copy the file name I am editing I could press Spacebar, which offered about 15 further keys, such as f all functions to do with files, b for buffer functions, w for window functions, etc. Once i pressed f, then I see all the functions possible on a file, including Spc-f-y for yanking the file name. This made the editor auto discoverable for me, almost like jumping to Windows 3 after years on MS-DOS.
> While emacs is a terrific editor ... it is not easy to use.
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.
Emacs is mostly just unfamiliar. It's also a little bit opinionated, and out of the box its opinions have a little bit of distance from most GUI editors.
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.
I haven't downvoted you, but I wouldn't recommend Vim either, and it's my favourite editor. Vim is notorious for trapping users, they don't even know how to exit the program!
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:
> Vim lists `:q' and `:help' prominently in the middle of the screen when you first start it.
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'm always 'that guy' who will eventually run 'sudo yum install emacs-nox' on any of our dozens of EC2 instances I'm shelled into if I'm working with it for more than a few minutes.
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.
It's 10MB uncompressed because go compiles libraries statically in the binary. 10MB is not really a big lift, and static compilation makes binary distribution much simpler.
I don't have any objection to packaging emacs with the OS. Actually, it comes with macOS, although without graphical support (/usr/bin/emacs).
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.)
>I beg your pardon, but since Linux is increasingly used nowadays in quite resource constrained embedded devices, MB definitely does matter.
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.
I don't entirely agree with coldtea either but in defence of this project it is very easy to shrink the ELF binaries that Go spits out as there's a lot of debugging hooks in there that arguably you don't need on production boxes:
Sure, my meaning wasn't to talk down the project itself, it looks neat! The "MB does not matter" just jumped at me (somewhat out of context, I have to admit) since I work in the embedded land, and the pain is sometimes too real there.
> This looks like it's aimed at being a better nano, not a better vim
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
If someone eventually writes a replacement for micro, it will be called milli, I imagine.
The advantage of Nano is that it is written in C, has zero required dependencies other than libc, and the compiled binary is 200 kilobytes. This makes it possible to include it in the base system, even on very tiny distros.
(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?)
It adds a massive new dependency to the build process for base system. C is itself a massive dependency, but it's already there for pretty much everyone.
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.
No, the C compiler. Both gcc and Clang are pretty big, even before you account for the standard library. I suppose you could get away with something like tcc, though.
It isn't, except for the fact that most people who can code low level programs know it. But what you don't want into consideration is pretty much the important part of shipping a software you want to proliferate easily.
Micro also has zero drpendencies after it's compiled. And Go makes cross compiling easy as childsplay: just set two env vars, type go build and you're done.
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.
Fun fact: on Linux, mac OS and BSDs, it does that by invoking syscalls directly. Syscalls are not considered a stable API on those systems by their respective developers. This means that your precompiled zero-dependency binary will just stop working next time Apple changes or removes a syscall: https://github.com/golang/go/issues/16570.
Coincidentally, code written in C doesn't have that problem.
Linux does, yes. MacOS and BSDs do not. (Neither does Windows - but so far as I can see, Go doesn't try to invoke the NT APIs directly there.)
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.
I am not all that familiar with kernel/low level programming, but wouldn't the C API/library internally use syscalls as well? If a C program is written with a dependency on a syscall, and this syscall is changed. Does the code still work after, or does it need to be recompiled with an updated compiler?
The compiler doesn't really play a role in this. If a syscall changes, then you'll need to change the arguments in the C code that invokes it.
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 system's C library would use the syscalls directly and the application would use the C library routines. So if/when the OS updates the syscall ABI, it would also update the system's C library to use the new syscalls, and the application would continue to use the stable C library API and get the new syscalls under the covers automatically.
I would rather say, it's a matter of having libc and kernel developed as a single package ("base system") by the same people, and versioned together, versus having the kernel and the userland separate.
Because you want to run it on your favorite platform, which might not be x86 and thus need compiler support? I wrote my own editor for exactly this reason: to always be able to have it on any platform.
Instead of nano what I want is something like microsoft edit. Complete with all the CUA style shortcuts (alt-f for file menu, ctrl-s saves, ctrl-arrow keys for moving, shift arrow keys for highlighting).
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.
It should be relatively easy using Free Pascal and its FreeVision text-mode UI toolkit. You get all the widgets, menus, scrollbars etc premade, complete with mouse support. They even have the editor widget with syntax highlighting already (in the text mode IDE; not sure if it's in the base library). All that's needed is to replace the default Borland-style shortcuts with CUA.
Speaking of Borland does anyone else remember the Brief editor. Was my goto for about a decade back in the early 90’s. Highly configurable, macros, column select and easily opened giant files.
Both would be very hard, my Outliner Lighto [0] program uses the Video unit that Free Vision uses and the main reason it cannot do unicode is that the screen is handled as an array of 8bit pairs (one byte is used for the character and the other byte is used as a pair of 4bit numbers, one for the foreground and one for the background) pretty much the same way that CGA had its text mode. All drawing in Free Vision is done by writing directly to TDrawBuffer types which are basically arrays of such cells. Also Free Vision specifically (this isn't a limitation of the Video unit) has a maximum width limit of 255 characters (technically it is the maximum width of a view, but the "desktop", the menubar, etc are all views).
You'd need a very massive overhaul to introduce unicode and more than 4bit/4bit color pairs to Free Vision.
Unicode would probably be a significant effort. It's actually a Turbo Vision port, and, as I recall, it still uses 8-bit strings, same as original did.
mcedit, the editor of the infamous Norton--err, Midnight Commander, was my best friend back in the good old days of writing php via ssh directly on the server of our university's LUG. It even supports block editing!
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.
Actually any vi editor is better than nano on slow connections. It has commands to move the cursor wherever you like with way less keypresses than using the directional keys.
I'm curious about the claim that nano is "best editor for slow connections." What features make that the case? Genuinely curious as it's not a factor I've considered.
Remember that over SSH you have to send every character over the wire. If you have a slow connection you'll probably prefer editors that avoid redrawing a lot and nano fits the bill pretty well. Although since they added syntax highlighting it's getting pretty heavy.
Fair point. Personally this is why I like to use mosh[0] where possible. For a period of time, my parents had satellite Internet and unsurprisingly the latency was terrible. mosh made any remote work during my visits tolerable.
I would fit in the same category of users like you. I've been using micro for a few months and I find it a very pleasant experience. My downsides so far are: haven't found a way to disable the somewhat aggressive mouse control, haven't found a way to disable coloring background (slow rendering on remote ssh) and paste buffers being messed up in recent releases. I just opened a 500mb csv which arguably was slower than using vi/vim but still fast enough and snappy after the initial load.
I’ve always wanted something like the old DOS edit or turbo vision editors with CUA key bindings, to the point where I maintained my own for several years around 2000. On Linux “ne” is not a bad choice, though I’d like an upgrade.
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.
In my opinion nano's biggest strength is that complete CLI beginners can use nano with almost 0 prerequisite knowledge. No reading man pages or tutorials, no accidentally hitting a key then having absolutely no idea how to get help, just "it's called nano and by the way ^ means ctrl".
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.
I can tell you from experience that it wouldn't take long to learn enough vim to make you look back on that preference and wonder why you didn't learn sooner. It's a shame that for many of us our first experience with it involves Googling how to quit out. That and a higher learning curve than most editors put a lot of people off, even after they've become familiar with it.
I'd praise vim as a 15+year vim user, but people crap on nano without even knowing the shortcuts it provides (cut/paste/move rows, justify a block of text, etc.) which are very useful when remote editing configuration files. Never in my life have I remotely opened a config with nano and thought to myself "oh damn I wish it was vi".
> Never in my life have I remotely opened a config with nano and thought to myself "oh damn I wish it was vi".
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.
>I can tell you from experience that it wouldn't take long to learn enough vim to make you look back on that preference and wonder why you didn't learn sooner.
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.
Fair point. But if it helps you feel any better I gave up several times and just barely got by with editing (very slowly) when I didn't have alternatives. What finally motivated me into overcoming my mental block was regular expressions of all things. When I realized how powerful (despite being flaky and inconsistent) regexes were in the Windows editors I'd tried I couldn't live without them and it didn't take long before I realized how much better vim was than even that.
Many people find themselves in nano for a quick change. They aren't interested in learning keybindings for an editor, especially (in the case of vi/vim) when those keybindings can accidentally clobber a chunk of your configuration file, sometimes without the user noticing.
Nano, as other comments have stated, shows the essential keybindings at the bottom of the screen, always.
If people don't know how to use vi/m I highly recommend running the vimtutor command. I've been doing it in some boring tutorials and after a week I feel almost component at it.
> 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).
Just in case people are still making decisions about needing to use an editor because you are doing something 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.
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!
That's a very good solution for accessing files remotely. However there are some environments where only a terminal and ssh client is available or useable (eg. Embedded devices). In addition sometimes you need to run things from the server.
You would need a second connection, I normally have a standard ssh connection open as well for things like that (as well as moving large files, running find in a large directory, or anything else that isn't reasonable to do on a fuse filesystem backed by remote files).
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.
Does Atom touch every file or something? Maybe running a stat or calculating git status? It's not slow to get the full tree of a big directory (not any slower than you'd expect that to be over the network) but touching a lot of files does slow things to a crawl.
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.
Unless this gets prepackaged in major distros by default ala `nano` then I honestly don't see the utility in investing in learning how to use this.
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.
Has anyone ever thought that the MS-DOS editor was one of the best CLI editors for complete beginners? I've always been disappointed that *nixs never ended up with something similar to edit. I suspected that irssi replaced ircii in a big way due to sane defaults, ease of configuration and a dash of color and I wondered if nano could've been replaced by similar principles.
At first I was going to agree with you, but I think this largely may be an artifact of where and how you started (and me too).
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.
I agree. I have found mcedit (midnight commander's editor) comes very close in ease of use and has a lot of power user features. Vim snobs will turn their noses at it, but I find it very comfortable to use for editing code. It is my main editor.
"Micro's number one feature is being easy to install (it's just a static binary with no dependencies) and easy to use."
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.
The main reason that Vi is the tool I use to edit config files is that I know for certain that Vi will be available on any normal Linux platform I'm dealing with - nothing to install.
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.
Very ignorant comment. Many people work across multiple machines (hundreds) which they do not own and cannot spend time "setting up" on each one. "Easy to install" means one can start editing with it in seconds. Do you really think compiling a local copy of emacs or vim on some strange machine counts as "easy to install"?
Compiling vim? Where do you not have Vim by default? Or could not install it with the default systems package manager?
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..
Why? I can see working on a handful of remote machines, because it's easier to set things up manually vs. set up a configuration management system at small scale. Otherwise you're editing Puppet manifests in a local text editor. What's the use case for editing files on hundreds of different machines?
I wonder what the target audience is for an editor like this is.
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'm a pretty hardcore Emacs user, and I'll just come right out and say it: I hate Emacs. However, the only thing I hate more than Emacs is anything else.
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.
I’m in a pretty similar situation with Vim. I don’t hate it, but compared to modern editors like Atom and Sublime I feel like I’m missing out on some features. Things like visual find and replace through a whole project, tight integration with Git, looking a lot prettier (even with a true colour terminal) make me a bit envious. And sometimes Vim just feels slow and laggy to me (I tried Neovim briefly but didn’t notice any difference).
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 :-)
I would say try VSCode with the Vim plugin. VSCode is much snappier than atom, the Vim plugin is quite good, the configuration files are easy to edit, built-in awesome git integration and project-wide search, and amazing plugin support. I moved from a super custom Vim to VSCode and I'm pretty damn happy most of the time.
Over at howl.io we're building an editor that's live editable like emacs. You can eval snippets of lua or moonscript code and they take effect immediately.
Lack of an intuitive and really good live help system is my main quirk with all editors, including Emacs. Of course, they all have some included help systems, but they tend to be slow to load (the worst!) or kind of cumbersome. I don't particularly like Emacs help system, for example. It shows you generic documents and it takes too much time to look things up.
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)
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.
I can't help but feel this is a shortcoming of some of the other apps you are naming. In particular, if they played well with $EDITOR then this wouldn't be an issue.
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?
IntelliJ's GUI is 65535x better than Emacs's GUI. I'd rather have Emacs as the editor in IntelliJ than Emacs trying to deal with whatever information IntelliJ is providing.
Doesn't change my assertion, though. If we want to hold up Emacs as being more embedable and playing more nicely with other programs, that same bar can be set for the other programs.
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.
The bar could be set for other programs, sure. But the question was only about why we use emacs and hate emacs.
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.
And to be fair, if you view UNIX as the IDE, it fits with the idea of small programs working well together. GLOBAL actually gets pretty friggin close to perfect for code exploration in most languages. I haven't tried the latest completions modes. Mainly because I just haven't bothered setting it up. It is borderline terrifying to me to see how reliant on ridiculously powerful and integrated IDEs some folks have become.
The target audience is people who casually use the terminal (probably over ssh) and need something simple to edit a config file with. This comes with all the basics that people expect from a graphical editor like Notepad++ and comes with familiar keybindings from CUA applications. I could see something like this being very useful for that use case.
That's actually a big market. People coming from vim will wonder what would you use it for when vim is so much more powerful. But this is a godsend to users who are used to gui editors. If they want something that behaves like every other editor and IDE they use there is very little available. In particular I don't know of any terminal editor that comes as a single binary and uses standard keystrokes like micro.
The reason they don't use those standard keystrokes is because for a terminal there is a much older standard that takes precedence regarding control characters. What's ctrl-z do? Background, or undo? It's nice for undo, but losing backgrounding capability is crippling if you use it.
The solution adopted by Unix-era GUIs, and the Macintosh, was to use a different key for GUI shortcuts rather than overloading Control. X11 generically calls it ‘Meta’, USB calls it ‘GUI’, Sun had Diamond, etc. It was only Windows that botched it, and the this-is-finally-the-year-of-Linux-on-the-desktop-trust-me-this-time crowd who slavishly imitate it while ignoring Unix experience.
It’s rare to need to background a console editor, and many can run commands themselves in the background. Combined with tabbed and split terminals not much if anything is lost.
> It’s rare to need to background a console editor,
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. :)
You may choose to do that but it isn’t required, I listed three alternatives that work fine and there are probably more. Going in and out of an app all the time is inefficient.
If I don't want a separate SSH connection for every tab, then some in-terminal level management is required. Additionally, it's not really that inefficient. It's no different than alt-tab in windows to background and foreground apps. In this case, it's like alt-tab when in a remote desktop connection.
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 wasn't complaining about Micro. I wasn't complaining about vim. I was just noting why terminal applications don't generally use those same key bindings historically, and why it still matters today. The only reason we are off in the weeds like this is because of your assertion that it's rare to need to background a terminal editor, which doesn't match my experience at all.
I just open a new tmux window per-file I edit, named after the file. Well, I do still bg vim processes sometimes, but mostly I do the per-window vim thing. I even have a vim wrapper to do this so that editing files from cscope automatically starts a new tmux window with the vim in it and returns control to cscope.
It requires a modified setup, but you can set vim up to open multiple unsaved files in a single process. Not splits ir windows, but buffers. I have bindings set up to quickly do :bn and :bp and :bd. Your tmux usage sounds like mine, and if you did not know that there was depth to vim buffers this may be valuable to you.
I'm aware of stuff like that, and things like nerdtree. In the past, I've had many boxes I might end up on so I kept coming relatively stock to the distribution. In the last four to five years it's been primarily one box, so I've finally started putting in more advanced features slowly.
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.
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.
Thanks for your interest. I've added a couple of screenshots to the readme. I usually run ozette in a terminal filling one monitor, with 2-3 files open. It works fine with more, but you just can't see much of their contents; still, seeing the edges of the other files in a stack behind the active tab somehow helps my sense of spatial navigation.
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.
Windows doesn't have sshfs, do they? If it did, you could just mount the remote, and use whatever UI editor you want. I do this with gvim (but on Linux)
Coming from a Windows background, Vim/Emacs are alien to me and Nano feels underpowered and weird. For lightweight text editing, this appeals to me much more at first glance.
I would really like to see a fully featured terminal based editor that is built with modern keybindings in mind. I've given Emacs a solid chance but ended up switching to Atom (weird keybindings and configuration that kept breaking made me leave in the end). I like most things about Atom. The package system. How it's configured and navigated. But there's a simplicity (and memory footprint) of the terminal based UI that is missing to really make it the perfect editor (for me).
Agree. Though micro looks very good as a light weight editor for programmers, arguably better than vim in some way, it cannot move (neo)vim users like me away. Borrowing Linus Torvalds words on why he is using micro-emacs,
One use case would be a fallback editor for junior developers. It's still important to have syntax coloring for things like config files, JSON files, editing shell scripts and writing Git commit messages; and you can't always use the IDE for these things:
* 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...
Please. Nowadays vim tells you how to quit. If you press control c, it clearly explains how to exit. I learned vim a few years ago, and immediately figured out how to exit it (just do what it says!) and by now it's my main editor and I love it.
I use VSCode for 99% of my work but I have EDITOR=micro for quick edits and for all of my git message writing. I don’t want to load a vscode session just for a quick commit message, but I want longer free form than you can achieve with “-m”. I also bind save and quit to a single key combo for quickness.
We need a better cross-platform terminal! Not editor. The current state of cross-platform terminals is fairly poor. Other than Alacritty[0] there hasn't really been any new innovation here.
I think we need a standard which allows terminal application to be as featureful as full gui applications. And then get all the most common terminal emulators to follow it.
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...)
Termius.com I've come to enjoy, it is an electron app but has been reliable on Android, Ubuntu, Win7 & chrome (although chrome app is going away) on Ubuntu it does leverage snap like this editor.
I understand how rewriting the wheel to thoroughly learn a new language can be exciting, but please avoid the “betterism”. No, just because you’ve rewritten something in go doesn’t mean it’s better, it’s just a case of building your little space where you can claim cred.
Fair point, but it might be better, so without comparing nano to micro yourself, it's hard to judge them, but it's true that 'better' is very subjective.
This. I'm a loyal Emacs user (used Vim a couple years before migrating to Emacs and always kept it around) but I must confess: I'm in love with kak.
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.
The source code for this is a really nice read, I just read the whole cmd/micro/micro.go like some prose. But one thing jumped at me:
if err != nil && !strings.HasPrefix(err.Error(), "function does not exist")
I wonder why most modern languages don't provide symbols a la Lisp or keywords a la Ruby, which would allow the above comparison to be a pointer comparison instead of a stribg one.
Edit: add the missing "don't" before "provide symbols".
A string check for an error type in a typed language is a shortcut/laziness really. There's more complex ways (which are less elegant) to typecast the error type into a "concrete" type and figure out if it's really the issue you are looking for.
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
It's a great editor,not everyone needs the superpowers of vim, the best part is that it's very easy to customize since Go is a very readable language (not on the level of Python but still).
One thing micro does very well is scrolling like GUI editors. It doesn't move the cursor with the scroll, and it will 'snap' back to where the cursor was if you begin to type. Always hated how other terminal based editors move the active cursors down/up on scroll.
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.
This is what i gathered as well? Maybe an alternative for nano-users? I’m not sure which space this editor tries to fill. Non the less fun project and always interesting to see new terminal based applications.
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.
I use what I get, if I have a nice config with Vim, I'll use it (badly, but it works well for me). Most of the time I'm happy with nano, assuming it's a one time edit thing like /etc/hosts, or I'm copy-pasting something into a file.
We keep hearing about network effects in social media networks, but as an Engg who works with multiple systems (personal, work, EC2, EMR, etc etc.) I do feel that when it comes to text editing tools as well, there is a network effect that comes into play.
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!
For teaching a noob how to edit in commandline nano is always a go to for me. I often use vim if I want to show someone some code and don't want to look like a idiot fumbling for a mouse. If I'm on a long stretch of programming I prefer sublime for awesome multicursor functionality and prettier text than a terminal. Haven't tried this micro but if the config is easier to learn than the rest then that's a obvious plus.
This look great, but miss something I like about nano and the old freepascal editor. It not show the menu!
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!)
can someone explain to me how this has mouse support? I thought mouse selection / click information simply wasn't passed from terminal emulators to the apps running within them. I get how it works in something like MacVim but how is it that this has it but AFAIK vim and emacs haven't been able to add mouse support in the terminal in 20+ years of development even though both support it in the gui versions?
gvim -v (and set mouse=a) from the terminal and emacs xterm-mouse-mode are both at least 10 years old.
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.
Stop complaining it doesn't look like a replacement for Vim/Emacs:
> 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 pinchhttps://micro-editor.github.io/about.html
People are mentioning (not complaining) that it's not a replacement for vim/emacs because the discussion is on a web site largely frequented by software professionals. Toy tools are not well-regarded here, nor should they be.
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 know this is a joke, but in the past I've tried using ed just for kicks. Is actually quite illuminating. That was right around the same time that I realized that sed and grep are packaged ed functions.
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.
Not only that, but there's also ex which was an improved version of ed. ex later got a visual mode called vi. In vim, you can run it in ex mode with the -e parameter. You can also enter ex mode using Q or gQ depending on your vim configuration.
Yeah! The whole history of vim is sort of what kicked off my interest in Unix history! For those not familiar with the story of how Ken Thompson came to write ed, there's a short fun read here:
It was the default editor on the AIX systems we had at college, not the usual vi, for some reason. This was in the mid-90s. Wrote a hell of a lot of code and Usenet posts in it. Also my first HTML homepage in '94, and my first Java in '95!
