Live data from Hacker News

GNU Nano 4.0

nano-editor.org

141–150 of 154 posts

Re: GNU Nano 4.0

#141
post #3

"nano" is an interesting creature - it was originally developed as a replacement for the "pico" command that shipped with "pine" (an amazing curses-based email client) because the license on pico was just not really clear. I still use nano 50% of the time because it's so easy to jump into a file, make some quick changes, and jump out. Plus the mark/cut/paste keystrokes are seared into my memory after years of use.

I would recommend micro. It's simple like nano, but has full mouse support. The only real downside is that it's not installes by default.

It's still a bit buggy. It sometimes freezes over ssh and randomly misinterprets keypresses/mouse signals if done too fast.

Re: GNU Nano 4.0

#142
post #76

Earlier quoted context omitted.

I'm a GUI dev/UX/education designer. Nano/pico to me are the only cli editors remotely suitable for ordinary human cognition. I have faint interest in the Emacs ecosystem, but wish it took basic ergonomics into account more seriously. I do understand I could get used to the lack of affordances but life's too short, perhaps. I understand keyboard usage wins you speed but not sure it's worth the general unpleasantness.…

It is not a human cognition problem. It's a motivation problem. Lack of motivation to take a few minutes to learn a keyboard command that will save you orders of magnitude more time in the future than you spend learning it. With the GUI version, what do you have to learn in emacs? In gvim, you have to learn how to switch between normal and insert mode, but I can't think of anything else basic that can't be done in th…

I'm not convinced this is true. I have spent a few weeks getting used to both emacs and vim and did end up going back to an IDE for proper development and nano for small editing. I'm not convinced that those two editors are worth the time investment that they require to be even remotely usable, even for the average software developer.

Re: GNU Nano 4.0

#143
post #76

Earlier quoted context omitted.

I'm a GUI dev/UX/education designer. Nano/pico to me are the only cli editors remotely suitable for ordinary human cognition. I have faint interest in the Emacs ecosystem, but wish it took basic ergonomics into account more seriously. I do understand I could get used to the lack of affordances but life's too short, perhaps. I understand keyboard usage wins you speed but not sure it's worth the general unpleasantness.…

It is not a human cognition problem. It's a motivation problem. Lack of motivation to take a few minutes to learn a keyboard command that will save you orders of magnitude more time in the future than you spend learning it. With the GUI version, what do you have to learn in emacs? In gvim, you have to learn how to switch between normal and insert mode, but I can't think of anything else basic that can't be done in th…

I believe this discussion is a part of a wider cultural gap and differences in understanding. I have been researching these differences for a decade or two now, and would like to understand them better.

That's why I would like to understand where you're coming from.

First, I'd like to verify: Do you think motivation isn't a human cognition problem?

Second, it appears to me you are making a wide array of assumptions about my preferences and my goals, as well as about what I find difficult or easy.

For example, you appear to assume that were I to choose rationality (?, i.e. not carrying "negative bias/emotion") I should value speed over of a host of other qualities of interaction design.

You seem to imply that committing to a specific kind of interesting, but very quaint visual/interaction style, i.e. the interaction constraints of a terminal UI, are a price worth paying for the speed of operation gained. Am I correct that you are implying this?

Keyboard shortcuts are not an exclusive feature of terminal UIs. I have a strong preference for UIs that comply with, for instance, the well-researched heuristics from the field of human-computer interaction. Terminal UIs are generally a lot more challenging to design to comply with them (for general audiences). Also visual hierarchy and a host of other beneficial properties are harder to achieve.

https://www.nngroup.com/articles/ten-usability-heuristics/

Yet, certain types of expert users tend to prefer - in my point of view - extremely arcane UIs, as they fit those users' style of operation.

They do not seem to fit mine. I want to emphasize that these are my current preferences, and you may well be right that I would enjoy the speed of emacs/vim usage. So far though, no one has bothered to sell them to me in a way that I personally would find convincing.

Re: GNU Nano 4.0

#144
post #125

Earlier quoted context omitted.

So you ask that team to install Emacs (because you're less likely to mess up config with a proper/familiar editor) and they just say no, forever?

Probably, yes. If you're lucky, it might get rolled into the next deploy/upgrade. Luckily, you usually don't need to do extensive editing there, because you usually can't change much. Most of the changes you'd want to make to config files, etc. also have to go into the next deploy or through some change management process anyway. You definitely get used to using vi, though.

I suppose I have been lucky. If I ever actually had to edit something critical on an unfriendly box, I suspect I'd still just do it in Emacs via tramp because I know I'd be less error prone. But as you suggest, for many years now I've experienced a strict divide between config changes, which are managed properly and not just done as ad-hoc edits, and boxes that are meant to be interactive, in which case the environment is tailored to the users.

Re: GNU Nano 4.0

#145
post #68

Earlier quoted context omitted.

Vi's not too bad. 'i' to edit text. ESC to get out of editing. ':w" to save changes. ":q" to quit. ":wq" to do both. ":q!" to quit without saving. "hjkl" for navigation in case the arrow keys don't work. That's enough to get by for quick edits. I haven't used vi a ton in my life, but I've managed to remember that much.

Yeah, but you NEED TO KNOW THAT before use it. With nano, all is straight in the UI. That is powerful, and so obvious. Why Vim/Emacs not have that?

I definitely agree with you that nano is more intuitive and certainly much more beginner-friendly.

Just saying that vi at its most basic level isn't bad at all. The user only has to remember i,esc,:w,:q,:q! for basic editing. That's not much.

But I do agree that it would be nice if vi / vim would simply list those commands when starting the editor for those who have never used it or haven't used it in ages.

Re: GNU Nano 4.0

#146
post #118

Earlier quoted context omitted.

Legacy, more than anything else. Nano has been a thing for decades, and it will likely be a thing for decades more. Are there better, more powerful editors out there? Sure. But just like vim, you can expect to find nano pretty much anywhere, and if you need to make a quick change, say to a configuration file on a bare-bones system, that's nice.

You're assuming Linux. BSD distributions don't install nano by default. vi is a mandatory POSIX utility, nano is not.

[deleted]

Re: GNU Nano 4.0

#147
post #87
post #47

Earlier quoted context omitted.

I like the idea of hard wrap, line of code shouldn't be longer than 80 characters... sure it's confusing for beginners + sometimes data shouldn't be hard-wrapped, but in general (imho) it's better than worse

Nano is a text editor, not an IDE. There's no reason why every text (not just code) should contain less than 80 characters in every line.

Can you explain your thought process here? I believe the idea is that old terminals were 80 characters wide. Also, even with modern monitors it can be nice to have shorter lines so you don't have to move your eyes/head as much. I can't think of why the rule would be specific to source code or why it would apply any differently to other forms of text.

Re: GNU Nano 4.0

#148
post #137

Earlier quoted context omitted.

When I'm not using an IDE, I'm a vi user because it's always there. When my /usr on FreeBSD has issues, vi is in /bin. OpenWrt ships with vi. I honestly have no idea if Emacs is any better, but not being a default makes it a non-starter for me.

Do you really have that many occasions to work in an environment where you can't ask for/install a package? Limiting yourself for such rare occasions just sounds wrong.

Production corporate environments are often firewalled/locked down. To change anything you have to go through layers of dis/approval. You are generally stuck with the defaults till the end of time.

Re: GNU Nano 4.0

#149
post #57

Earlier quoted context omitted.

Why nano? nano is sane. With Emacs/VI you need to bring a HUGE mental framework to just use it. And maybe, with luck or some years of pain training, to just EXIT it :) --- Vim/emacs are powerful. Nice? Never. Easy? never. Good for most common editing task in the terminal?. Nope. Claim that Vim/Emacs are good is like say "why people use Sublime Text when Eclipse is so much better?" Except, with eclipse, you know how e…

Vim is how much you want to get out of it. I looked at Vim, thought about its value proposition, and decided only to learn the most basic commands from a cheat sheet. That makes it more productive than Nano already. I know other people who aren't Vim fanatics at all but have occasional work in the terminal, and they too also just learned the most basic Vim commands and have the most basic Vim configurations, if at al…

I don't disagree with you at all and my reply should not be construed as criticism, but I just want to point out how funny the line, "Vim is how much you want to get out of it," is.

Re: GNU Nano 4.0

#150
post #118

Earlier quoted context omitted.

Legacy, more than anything else. Nano has been a thing for decades, and it will likely be a thing for decades more. Are there better, more powerful editors out there? Sure. But just like vim, you can expect to find nano pretty much anywhere, and if you need to make a quick change, say to a configuration file on a bare-bones system, that's nice.

You're assuming Linux. BSD distributions don't install nano by default. vi is a mandatory POSIX utility, nano is not.

This doesn't help the problem of knowing what to type on any system up-front, but fwiw, FreeBSD ships with a nano-like editor in the base install, ee(1).
Post reply on HN