Nano to remain in GNU | Hacker News Reader

Nano to remain in GNU

lists.gnu.org

145 pointsIanvdl65 comments

This is good news: It's also good to actually see RMS actually compromising.

Also, nano is actually a useful tool, despite its reputation as the editor for those who don't know what they're doing. It's an excellent editor for quick edits that aren't worth pulling up emacs for. Although I would never reccomend it for Real Work, that's not really its intent. And it owns its field, having crushed all competition save vi, which is really in its own class.

Also, nano is frankly a lot more powerful than a lot of people give it credit for: It's just not programmable, which is a necessity in editors these days.

> as the editor for those who don't know what they're doing

To be honest, I do think of nano as exactly that. Let's say "the editor for newbies", which sounds slightly less condescending.

Being the editor for newbies is not a bad thing. There are, at any given point, many newbies who just want to make that one change to that one configuration file without learning a whole programmer's text editor. There are, by now, probably plenty of people of who use GNU/Linux just to surf the web and read their email (and run LibreOffice or GIMP), who don't ____ing care about text editors except for that one time they need to add an entry to crontab or sudoers or something.

If you have never touched vi before, its user interface at first seems like a slap in the face (to put it mildly). Having used vim as my editor of choice for a couple of years at one time, I still remember, vividly, the first time I tried to use it. It was no fun at all. The same goes for emacs (which I love dearly).

If you want to do serious programming / system administration, learning one of the advanced editors is - at the very least - good advice. But these days, such people are probably in the minority, even on GNU/Linux. And having an editor the rest of the population can use without requiring a Ph.D. in emacsology is a Good Thing, IMHO. It's not something one should feel sorry or condescending about.

As someone who has used Linux since 1999 (starting with Slackware) and FreeBSD and OpenBSD since the early 2000s, I'd say I'm no longer a "newbie". Yet, I use nano daily because it's so simple and accessible. You only need to remember a few key combos, and for basic edits there is simply no need to break out vi or emacs or a GUI editor.

A simple, useful tool does not always equate to "newbies only". In fact, I'd say it's the UNIX way: A simple tool that does one job really well.

Or to put it another way: Why would I break out my 30 piece combination wrench set when I just need to turn a nut a little tighter with my adjustable wrench that's right there next to me?

When you work with the combo set from 5 to 16 hours a day and immediately know the size of the nut on sight, you feel exactly the opposite sentiment.

Probably not the average use case though.

Excellent point, and I'm getting there with all the work I've been doing restoring my Bronco.

...That's actually my point, kind of. While I wouldn't wish nano on anyone working on a large project, a lot of unix administration work (well, at the level of the system on your desk, anyways... professional SAs have a lot more to do, and should be feared and respected) is light text editing: that's precisely nano's problem domain.

I used nano exclusively for years, and though those days are gone, I don't appreciate people who look down upon it and its users, just because it wasn't built to compete with emacs.

I've been programming for about 5 years (probably not "serious programming") and I use GUI editors, and nano is pretty similar to them.

Fair points. But this is also true:

> There are, at any given point, many [non-]newbies who just want to make that one change to that one configuration file without [using] a whole programmer's text editor.

> There are, by now, probably plenty of people of who use GNU/Linux (...) who don't ____ing care about text editors [when it comes] for that one time they need to add an entry to crontab or sudoers or something.

> If you want to do serious programming / system administration, learning one of the advanced editors is - at the very least - good advice. [But even then, a simple editor is always useful.]

My point is: not just for newbies.

In a way, maybe it's good it's not programmable. This ensures that on any machine or environment you see Nano, you can expect it to behave exactly the same. If you want something super customizable you can just use vi(m) or emacs.

Nano is like Windows Notepad but for the CLI. It does one thing one thing only, no matter where you are.

This is exactly what I use it for. When I'm ssh'd into a server without my vim config, I prefer to use nano simply because I'm so used to my own vim. Using any other vim config is actually difficult, especially since I'm not actually that knowledgable about vim.

Nano takes the cake in this situation. It's everywhere, it's easy.

I understand why nano was designed that way, but it does mean it's unsuitable for Real Work. It works well for light text editing, which, let's face it, is probably the most commonplace activity on a given unix system.

I would assume that the compromise in this case that some developers of nano will do copyright assignment while others won't, and FSF will still do GPL enforcement.

The previous dispute as I understand it is that FSF has a all or nothing approach to copyright assignment. Either a GNU project assign all copyright, or a GNU project assign nothing and FSF do not enforce the projects license.

It's worth also keeping in mind that there isn't necessarily anything wrong with it being an editor for newbies. Emacs can be pretty intimidating to learn straight off.

It's lightweight: my point is there are reasons for using nano beyond "d'oh, I don't know what I'm doing." You don't bring up emacs to edit fstab, or your hosts file. As a result, it's popular among newbies. But that doesn't mean it's without merit, as is all too often implied.

With emacsclient you can easily open those files, quickly, in Emacs; in fact, I would argue you should. fstab has its own editing mode in Emacs with syntax highlighting and so does hosts.

...do you really need syntax highlighting for fstab?

nano is great! OK - it might not have the feature of VIM and has some keybinding that need to be changed out of the gate (newer nano version you can do this), like changing Cntrl-W to Cntrl-F (Search) and a couple of others that just to make things sync between different programs.

Good to hear. Nano's up-front display of the core key combinations has been a source of relief for people getting dropped into a terminal editor for ages. Wish more distributions would set nano as the default $EDITOR instead of vim.

Oh my god yes. nano, moe, and JOE are more lightweight than vim, and have better ergonomics. I can understand setting $EDITOR to nvi, mg, or similar, but setting it to vim is ridiculous: Vim is in Emacs's weight class.

The worst is when someone who's never used Vi before gets thrown in there after running, eg, 'git commit'. Can't Google how to quit because they don't even know the name of the program!

Google actually quickly directs you to the needed information: http://stackoverflow.com/questions/9171356/how-do-i-exit-fro... (first result for "quit git editor" for me)

Happy to see the conflict settled! Here's what's in the news entry for the GNU release:

    With this release we return to GNU.  For just a little while
    we dreamt we were tigers.  But we are back in the herd,
    back to a healthy diet of fresh green free grass.

Can anyone give some context info? Was there some conflict between GNU and nano that has now been resolved? What was it about?

Nano's new maintainer (Benno) didn't like GNU's maintainer agreement and refused to assign copyright of his contributions to the FSF. So instead he forked the project to maintain it ouside of GNU.

HN discussion from two months ago: https://news.ycombinator.com/item?id=11953044

Some additional background - Why the FSF gets copyright assignments from contributors: https://www.gnu.org/licenses/why-assign.en.html

tl;dr: for GPL enforcement.

Which has been mostly okay with widely-distributed ownership, but was a problem in Christoph Hellwig's case against VMware recently. So there's an actual problem of enforceability, versus the project-hampering PITA factor of CLAs at all, e.g. https://lwn.net/Articles/443989/ It's a seriously tricky balance issue.

As mentioned in the post, it was about differences over copyright assignment, which has apparently been resolved. The wikipedia page says slightly more about it: https://en.wikipedia.org/wiki/GNU_nano

Anybody else use ed(1)?

My main editor is acme, and when I need to do large edit jobs on remote servers I control I use sam. However, when I have to edit files on servers I don't control, or when I have to do a quick edit job and I don't have a sam terminal started yet, I use ed.

Unlike all other editors, ed doesn't erase the screen. I find this extremely useful. Also, ed is always the same. Vi is not always the same on different systems. Sometimes it has syntax syntax highlighting by default, forcing me to make effort to turn it off, sometimes nocompatible is set on or off, etc.

Ed is always the same and has no settings.

Sometimes inside my acme session I run win(1), and sometimes in my win sessions I ssh to some system and run ed inside acme.

I forced myself to use ed exclusively for a week some years back, and since then I stuck with it.

My attempts at using ed end up like the session illustrated here: https://www.gnu.org/fun/jokes/ed-msg.txt

> Ed, the greatest WYGIWYG editor of all

It's not often I can type lol and literally mean it, but this is one of those times.. lol :D

Ahh. Yes. I'm not that bad, but I'm not great either.

Actually, I do use ed(1) quite regularly. Sometimes I invoke it in conjunction with rlwrap(1), but plain 'ed' or even 'restricted ed' is just fine. :)

Ever had display problems using ncurses-based programs over a serial connection? I did and I was happy to have a line editor at my disposal…

like vi, ed is a tool that everyone should know how to use. If your system is well and truly FUBAR, to the point that all but /sbin is gone, and termcap's missing, you need to know how ed works. But even kt himself has given up on using ed for the day-to-day (he uses sam, which is probably what vi should have been...), so it's clear its popularity has waned over the years. I myself would rather emacs any day.

As for acme, I never got on with it. It's too graphical for my tastes: call me old-fashioned, but I like to have my finger on the keyboard when I edit (sam in a tiled wm is about as far as I'll stray in that direction). OTOH, it does have some really cool features... However, we Emacs users don't get jealous of features: we steal them...

grins evilly

> If your system is well and truly FUBAR, to the point that all but /sbin is gone, and termcap's missing, you need to know how ed works.

I would agree with this a 10+ years ago, but I think we created better technologies since. I'd rather say that if your system is so broken you should know how to 1) snapshot it for analysis, 2) replace from original image, or orchestration. Using ed may be fun, but why not just move the snapshot to a working system instead? And apart from massive filesystem corruption, why would we ever lose /sbin in production in the first place?

No, not sbin, your shared libraries, and/or termcap. Those are easily loseable, especially if /usr, /share, or /lib are on a separate partition.

Although yes, it's not the problem it used to be.

When I first read this, I thought it was satire - who in the world is still using ed? At the second reading, I realized you were serious and decided to check out ed (which I only knew by reputation). Having worked through the info manual, it doesn't seem half as bad as I thought it would be ;-) Not that it's going to replace Emacs, but who knows, I might just end up using it occasionally...

It sounds like your vi may be a symlink to vim, which is default on some distros. vi should be identical across Unices and Unix-likes.

Not to mention ed is the standard editor!

ex is usually safe from the featuritis that grips vim

Yeah, that's the problem with poor scriptability, mixed with no dedication to minimalism or vision. This minimalism is one nice thing about vi, although I like my editors like I like my paper: scriptable.

It's a great editor, I use it all the time with new Raspberry Pi people. Since it's so simple to use we can focus on what we are doing vs learning on how to drive an editor.

Happy to see RMS was willing to compromise and keep nano in the hurd.

Context: https://news.ycombinator.com/item?id=11953044

See also, if you have time to read: https://www.reddit.com/r/linux/comments/4p9n7e/as_of_nano_26...

To be honest, I didn't realise that nano was being maintained, I sort of assumed that it was slowly fading out of existence. Honest question: does anyone here use nano for anything? If so - what are you reasons for using it / what do you like about it?

The times I need to edit a text file in a terminal are very rare (config is managed, code comes from git). I already have a GUI text editor of choice, so I've never felt any need to memorise vi/emacs (aside from how to save and exit). nano has the commands right there onscreen if I've forgotten.

ah yes, interesting, thank you for replying!

Nano lists its shortcuts in the window, like most modern GUI software. This is helpful for beginners, but also for me when I haven't had my morning coffee and suddenly find myself in a text editor. I enjoy using it, but I also like that it's discoverable from within the program; that strikes me as good design.

OK interesting, for me I personally always feel lost in nano as for me it feels like it's a gui app trying to exist in a console, but that's me - thanks for replying to my question!

FWIW any application launched from the shell that spawns its own full-screen context is a 'gui app trying to exist in a console', including its competitor editors; at least nano tells you now to use it once you're stuck inside it.

I don't spend enough in Linux/BSD* environments and/or editing text to make learning vi/emacs worthwhile, but need a terminal editor for maintaining my remote server. nano is ideal for that role - minimal functionality + shortcuts shown at all times means I don't need to learn anything, but can make any quick edits I need.

* I know both can be used on Windows, but a GUI editor feels like a more natural fit to me in that environment.

Not trying to force either of those on you or anything like that, but just a quick remark: both Vim (although not vi) and Emacs have fully functional GUI “modes” (in fact, I think overwhelming majority of Vim/Emacs users use it in GUI mode). They might not look native in Windows though.

Atom with a vim plugin or sublimetext are good windows options for vim.

It was cool to have when I first worked with a Linux command-line and didn't really get any introduction. The instructor just told me to type in "nano filename.txt" and from then on I could work out the rest.

Not that it was terribly necessary. Another instructor told people to use vim, showed them around for half a minute and then they could do just as much with vim as I could with nano.

The previous HN discussion for some context: https://news.ycombinator.com/item?id=11953044

Fair question: how does it matter?

I assume: in that GNU will continue to provide hosting and mailing list resources.

Why was it at risk of leaving?

I was always a fan of mcedit.

edit: not constructive

It's a substitute for pico, not vim.

I do, and I do not consider it a vim substitution, it's rather a light-weight console-mode editor that is installed on most systems and easy to use.

There's also GNU moe!

https://www.gnu.org/software/moe/

JOE clone?!?

I wonder what motivated `moe`.. and when... joe has been a great option for a terminal editor forever

I'm guessing because there was a period of time where joe's maintainer worked on something else besides joe, and it looked like the project got abandoned already.

I used it back a while when I was too lazy to use vim. Now I don't know how to use it anymore rofl

Reply on news.ycombinator.com