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.
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.