Hacker News Reader

Comment by Lazare | Hacker News Reader

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.

View on HN

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.

Emacs has a GUI with icons and menus and tooltips and all that.

Isn't that what a true beginner would use anyway instead of the terminal version?

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.

vi(m) is usually included by default and is no easier to use for a beginner, so why not emacs?

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

For some people on the move data transfers are expensive, even if 80MB isn't much that adds up very fast.

Because modal editing is where it's at!

>Emacs has a GUI with icons and menus and tooltips and all that.

Which is still nearly useless without knowing of lots of Emacs arcana.

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.

Cocoa widgets for text entry in macOS support Emacs keybindings by default. Yes, TextEdit too. You cannot get nearer to beginning users than that.

But yes, it takes a time to get used to. But that's matter of familiarity.

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.

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

On my computers anything that uses readline behaves like vi.

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

I think that "easy to use" means "easy to use from the beginning" most of the time.

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.

Spacemacs is amazing but it's almost an IDE at that point.

An IDE with the best embedded editor, Vim, reimplemented with elisp!

>why the downvote?

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

> Because MB don't matter

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:

https://blog.filippo.io/shrink-your-go-binaries-with-this-on...

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.

Obviously the MB don't matter in this case and for the target audience of the editor, not in general and in every context.

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

embedded boxes run something like busybox to get just the coreutils rather than including all the packages that ship with, e.g., debian.

https://busybox.net/about.html

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.

> they don't even know how to exit the program

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"

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

13MB only ? how come

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.

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

or maybe `limo`.

But can it replace mg?

pico => nano => micro => milli => centi ...

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.

Why is C an advantage?

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

Statically linked C programs are the easiest to ship. Copy and run. No runtime required.

Same with go

A feature of any AOT compiled language since compilers exist, nothing C specific.

Java and .NET would like a word with you.

You can embed their runtimes. I'm not saying that's desireable, just that it's possible.

When correcting someone on Internet be sure to know what you are talking about.

ExcelsiorJET, JamaicaVM, Aonix PERC, IBM Websphere Real Time, Xamarin on iOS, .NET Native, Bartok.

yes, good idea, let's make a modern console-based text editor that comes with IBM Websphere Real Time

C compiler backend support is pretty broad.

Probably the biggest understatement I've ever seen on HN.

Supported on virtually every OS and embedded platform in existence.

Abstractly, very much yes.

In the context of nano and editors, you also have to contend with POSIX, tty I/O, etc.

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.

>>> C is itself a massive dependency

the C standard library?

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.

lots and lots of edge cases, I minimal compiler can be kbs

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.

As easy as childsplay as long as your target is supported. I cannot run Go code on my router which runs OpenWRT... Nano works there just fine.

Go was likely never intended to run on space constrained platforms like Broadcom MIPS, but point taken.

What?

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 considers syscall API stable and there's a pretty hard rule of not breaking user space.

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.

FreeBSD also doesn’t break the ABI on major versions.

That's good to know, but it still means potential breakage every 2 years on average.

Historical accident, it is all a matter how libc of a specific compiler was implemented.

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.

Unless you'd want to contribute, why would you care what language it's written in? Why Go and not C++, Rust, D... ?

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.

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

The advantage for whom? Surely not the user.

Having been stuck on a system where the only editor was Ed, I'd say nano availability can be a big win for the user.

When I was a lad, I had to port ed in order to have a console-based editor.

(True story - A5000 with RISCOS back in about 1993)

Can we start a !Zap vs !StrongEd argument here? :)

(Zap wins, of course!)

The advantage for anyone trying to find out-of-bound exploits in text buffer handling.

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.

http://www.principiaprogramatica.com/wp-content/uploads/2009...

Nice, loved turbo vision. Wonder if they could update with Unicode characters and 256+ colors?

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.

[0] http://runtimeterror.com/rep/ol

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.

Brief was excellent, as was the GUI version Crisp. Superb window split implementation.

You should look at the joe editor :)

Have you tried micro? It has basically all of that.

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.

[0] https://mosh.org/

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.

Nano can jump too

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'm not sure if any of this will help or not:

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

The same for me.

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.

The joe editor is based on Turbo C

Have you tried mcedit? It has similar look and feel, unfortunately CUA keybindings does not seem to work

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

> nano is a terrible editor.

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

Have you ever tried JOE? It's what I used prior to vim ... https://en.m.wikipedia.org/wiki/Joe%27s_Own_Editor

I find JOE much more awkward to use than nano.

micro on the other hand feels a lot more like Sublime Text for the terminal. I like it. :)

I like Nice Editor or ne.

This one, micro, looks interesting. I’ll give it a try.

What's awkward about JOE?

JOE has jpico (nano like) jstar (wordstar) and jmacs (emacs) keybindings.

Nano is still my goto if I want to edit a config file really quickly.

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 use vim for development.

If you need to add a comma you forgot to a json file, nano is faster.

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've been using vim for over a decade.)

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

Checkout Jed, it's been around for a long time.

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.

When you forgot $EDITOR, ^O^X had your back. :)

Emacs?

Reply on news.ycombinator.com