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.
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.
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.
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. :)
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.
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.
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).
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.
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.
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?
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.
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.
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.
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)
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,
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.
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.
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.
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.
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.
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.
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 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.
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.
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?
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.
> 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 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.
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 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.
>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 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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
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 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.
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.
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 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.
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 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.
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.
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.
> 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.
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".
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.
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.
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!
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.
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.
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.
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!
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.
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 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...)
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!)
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).
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.
276 comments
[ 3.1 ms ] story [ 272 ms ] threadMost 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?
https://github.com/eugen0329/vim-esearch
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.
https://github.com/mawww/kakoune https://vimeo.com/82711574
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.
(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.
>>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.
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)
[1] https://www.youtube.com/watch?v=QOGPQY9LGKc
[2] https://github.com/lavv17/le
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.
https://busybox.net/about.html
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.
[0] https://mosh.org/
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.
[0] http://runtimeterror.com/rep/ol
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:
If someone eventually writes a replacement for micro, it will be called milli, I imagine.> 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.
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.
[1] http://spacevim.org/
Being written in Go, I don't see this as likely.
> 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
> 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.
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.
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
https://news.ycombinator.com/item?id=13633578
https://news.ycombinator.com/item?id=13300940
[0] https://github.com/jwilm/alacritty
https://github.com/evmar/smash/wiki/Related-projects
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...
[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!)
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.
Just a recommendation, csvlint, which is another Golang tool also is very useful.
The old editors are both powerful and arcane.