Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nano 5.7

lists.gnu.org

Post reply on HN
Print view View original

81–90 of 157 posts

Re: Nano 5.7

#81

Post by kstrauser »

valera_rozuvan wrote: post #5

I don't understand the people who dislike nano as an editor for the *nix system. After spending in it for like 30 minutes - it becomes an indispensable tool for quickly touching up text files anywhere you go to! No matter where I SSH to (*nix systems) - I always had nano available.

Nano has/had some surprising defaults. Way back when, I was using nano to edit some file or another in /etc. When I wrote it out, it "helpfully" justified all the lines by inserting newlines to make them fit in 80 columns. My mentor looked at me disapprovingly, uninstalled nano, pointed me at `man vim`, and said "you're using this now. Thank me later."

Thank you, mentor.

I don't know if nano still has that as a default on any system that's shipped in the last 20 years, but I always give it the side-eye whenever a system has `EDITOR=nano` set and I run something like `visudo`. Am I about to break the entire system? Probably not, but to be sure I exit nano, configure `EDITOR=vim`, and try again. I know vim won't trick me like that.

Re: Nano 5.7

#82

Post by kstrauser »

fouric wrote: post #67
valera_rozuvan wrote: post #5

I don't understand the people who dislike nano as an editor for the *nix system. After spending in it for like 30 minutes - it becomes an indispensable tool for quickly touching up text files anywhere you go to! No matter where I SSH to (*nix systems) - I always had nano available.

Emacs has had TRAMP[1] (transparently allows you to edit remote files in your local editor using an SSH client) for literally decades now, while SSHFS has been around for nearly as long, and even zeitgeist tools like Visual Studio Code have equivalent TRAMP-like/auto-SSH addons. The "it's not available on remote machines" line of reasoning hasn't been valid for at least 20 years (age of TRAMP), except for the case wh…

I love Emacs. I love Tramp. I love iTerm + Fish Shell more than eterm, though, so if I'm SSHing into a server it's from a terminal app outside of Emacs. In that situation, I'd rather use vim to make a quick tweak on a file than bounce to Emacs, tramp into the same machine I'm already in, and edit it that way.

Re: Nano 5.7

#83

Post by fouric »

zitterbewegung wrote: post #39
fouric wrote: post #31

As a vim and emacs user, I don't give nano any hate. I'm surprised when programmers use it, sure, but that's because if my profession was going to require editing text files for hours a day (which it does), I would be happy to trade a steeper learning curve now for a less unpleasant job experience later. I totally understand why non-programmers don't use it. If your job does not involve you editing text files for hou…

Its more like using the right tool for what you actually want to do. 0. Use cat and output to a file to really quickly make a new file from your clipboard or from the web 1. Nano is great for editing config / text files quickly and the learning curve is really low due to a more modern design. 2. vim can be reliably found everywhere on nearly any unix machine but the learning curve is much higher initial learning curv…

> Nano is great for editing config / text files quickly

emacsclient makes it just as easy to edit a text file extremely quickly with Emacs as to open a new vim or nano in place.

> emacs [...] initial learning curve is a bit low but then it gets higher and higher

Emacs's difficulty is, for simple editing cases that you could use nano for, only a little bit more difficult than nano, and certainly easier than vim - no modal editing, and you can learn the essential shortcuts (save, undo, open, close) in very little time.

I don't agree that the learning curve increases - more complex things require that you learn more about Emacs, sure, but my experience has been that it's about as easy to go from beginner to intermediate Vim knowledge as it is in Emacs, if not slightly easier due to the latter's better design and documentation.

> emacs [...] can't be found everywhere

TRAMP has been around for two decades now, making this largely irrelevant - https://news.ycombinator.com/item?id=26982916

Re: Nano 5.7

#84

Post by kijin »

bsharitt wrote: post #37
293984j29384 wrote: post #6

I never understood the hate Nano gets from vi users. Nano does many things quicker and easier than vi. For example, search & replace. Would I code in Nano? No. Do I use Nano to edit configuration files and make other small edits? Absolutely.

>Nano does many things quicker and easier than vi. For example, search & replace. There may be instances where Nano does something quicker but search and replace would seem to be a perfect example of the opposite where Nano has taken a quick one line thing in vi and turned it into a multistep process for simplicity.

Exactly. And that can be extremely useful for people who either don't want to or can't memorize the vi one-liner.

Nano is different from vi because it targets a different set of users. Many of them use the terminal infrequently, so you can't assume they'll ever build up the kind of muscle memory that makes vi so efficient. You can't even assume that they'll remember any commands, so the commands are displayed prominently at the bottom. There's a reason so many Ubuntu tutorials for beginners use nano instead of vi.

Re: Nano 5.7

#85

Post by ShakataGaNai »

Thank you Nano devs. I love it and continue to love it all these years later.

I'm happy to get in the middle of any vi vs emacs fight with the battle cry of "Nano for life!". The looks on their face is always priceless.

Re: Nano 5.7

#86

Post by kijin »

cesarb wrote: post #36
simion314 wrote: post #10

Earlier quoted context omitted.

Probably the elitist guys, the ones that have their identity defined by the editor they use, the language and framework and the Linux distro/DE/OS they use. Many people just need a tool that does a simple job but does it well, like editing a ini file and adding a line or a word, nano is great for that. (we all know that type of guy that has to tell everyone all the time that he uses Arch and Rust would have fixed eve…

> like editing a ini file and adding a line or a word, That's precisely the use case that has made me remove nano from every machine I administer since the 90s. Unless you're really careful to always start nano as "nano -w", its hard word wrapping will introduce line breaks where many configuration file formats (including ini files) don't expect, and it will do so in lines other than the one you're modifying. It's le…

I've never seen nano on any popular Linux distro hard-wrap long lines by default. Yes, it's controlled by a setting, and some people turn it on for some reason, but I just confirmed it's off by default (no need for any command-line flag) in both CentOS and Ubuntu. You might have been burned by a setting left behind by someone with a weird taste.

Re: Nano 5.7

#87

Post by easton »

iheredia wrote: post #11
valera_rozuvan wrote: post #5

I don't understand the people who dislike nano as an editor for the *nix system. After spending in it for like 30 minutes - it becomes an indispensable tool for quickly touching up text files anywhere you go to! No matter where I SSH to (*nix systems) - I always had nano available.

I pretty much agree and share the love for Nano, but - just as a comment - it happened to me that it wasn't available in some Red Hat servers. Depending on your regular work and the type of servers you SSH into, you could expect Nano to be already installed or not

That's actually the entire reason I learned enough vim to be dangerous, on EL7 and below they did not ship nano in the box and there was a project I was working on where we had a bunch of 5.5 systems that had busted network configs. That was a.. joy, to say the least.

Re: Nano 5.7

#88

Post by ch_123 »

zitterbewegung wrote: post #39
fouric wrote: post #31

As a vim and emacs user, I don't give nano any hate. I'm surprised when programmers use it, sure, but that's because if my profession was going to require editing text files for hours a day (which it does), I would be happy to trade a steeper learning curve now for a less unpleasant job experience later. I totally understand why non-programmers don't use it. If your job does not involve you editing text files for hou…

Its more like using the right tool for what you actually want to do. 0. Use cat and output to a file to really quickly make a new file from your clipboard or from the web 1. Nano is great for editing config / text files quickly and the learning curve is really low due to a more modern design. 2. vim can be reliably found everywhere on nearly any unix machine but the learning curve is much higher initial learning curv…

As someone who has invested time into vim, I can edit text files with it much quicker than I could with nano. I also suspect someone with sufficient nano experience may be as capable of coding in nano as I am in vim.

"Use the right tool for the job" is all well and good (I mean, who wants to use the _wrong_ tool for a job?) but can lead to false dichotomies around tools which are designed to solve the same fundamental problems/use cases. I would posit that the model you suggest only is applicable to people with limited experience with vim, nano (and/or emacs). I would generally recommend that someone picks one and runs with it.

Re: Nano 5.7

#89

Post by bombcar »

GordonS wrote: post #43
valera_rozuvan wrote: post #5

I don't understand the people who dislike nano as an editor for the *nix system. After spending in it for like 30 minutes - it becomes an indispensable tool for quickly touching up text files anywhere you go to! No matter where I SSH to (*nix systems) - I always had nano available.

I've installed nano on every Linux system I've ever worked on, if it wasn't already there of course. For me, it's so much easier to work with than vim, for changing config files etc. I only wish line numbers were enabled by default, or at least there was a simple and easily discoverable way to enable them.

echo "set linenumbers" > ~/.nanorc

Re: Nano 5.7

#90

Post by chungy »

jolmg wrote: post #71
jejones3141 wrote: post #69

Earlier quoted context omitted.

One thing I've found nano useful for: git commit messages. If the commit file is empty, that cancels the commit. Nano will tell me how many lines it actually wrote, so if I have second thoughts I can cancel with certainty. Nano may well not be unique in that regard, but I tripped over another editor that saved what I thought was an empty file as a single line with just the EOL character.

You can have a bunch of comments and empty lines, even with spaces, and git will still abort if you don't have anything else in the commit message. An EOL/newline character shouldn't cause the commit to continue.

There are overrides to make empty messages or including otherwise-comments, but yeah... you have to do such things rather explicitly. No way you can do it by accident.
Post reply on HN