Live data from Hacker News

GNU nano is my editor of choice (2021)

ariadne.space

201–210 of 303 posts

Re: GNU nano is my editor of choice (2021)

#201
post #39

There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…

> Replacing Vi(m) with Nano in the standard install was one of the most important UX decisions made by the major distros in recent years It sounds like you want a unix with the UI/UX of a different OS. If a user is coming from a world where editors have all coped MS-DOS edit and its notepad progeny then nano makes sense. I am sure this goes for whatever default editor comes with Mac. If a user is coming from a Unix w…

Are you arguing that discoverability in user interfaces is bad?

Re: GNU nano is my editor of choice (2021)

#202
post #180
post #39

There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…

If I forget to change the default editor in Debian and Nano pops up, I have to consult a search engine how to exit it. Just like other people do for Vim, except that Nano's interface is horrible. It is a weird decision, much like shipping Exim as the default MTA.

If you're googling how to exit nano you're blind. The one thing nano does right with its defaults is to list all the common bindings at the bottom of the screen

Re: GNU nano is my editor of choice (2021)

#203
post #177
post #39

There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…

Nano default key bindings are not standard either. They are less different than vi from a typical GUI input controls and having a menu at the bottom of the screen help, but they force the user to get used to yet another convention. I was considering at some point to create a patch to nano to have a simple option to switch to more common bindings or even ask the user on the first run about it. But then I discovered th…

The thing is that the most imporant commands are shown at the bottom and just editing a file and the exiting will prompt for a save. This is good UX. No surprises, the most likely thing the user intended is the default and doesn't require any app-sepcific knowledge.

I recall the very first time I was thrown into emacs because it was the default at university terminals (around 1993, I think). And I recall the first time I was thrown into nano (I think it was on Gentoo, maybe around 1999).

The difference in UX couldn't have been more stark.

Re: GNU nano is my editor of choice (2021)

#204

My editor of choice is vscode and Intellij, the only time I would use a command line editor is when I am sshing into a server temporarily and just want to make some small edits to a file. I know enough commands on vim to insert/edit text and exit, which works when nano isn't available on the machine and I don't have access to a package manager. But for everything else, I use a proper IDE. I setup sshfs with remote ma…

An ide provides very little that vim doesn't. If you think it does you're just ignorant about what vim can do. Nano is basically featureless though

Re: GNU nano is my editor of choice (2021)

#205
post #128
post #93

Earlier quoted context omitted.

If you look at how other (console) programs on the system work, Vi(m) is more consistent than Nano. ed, sed, awk, readline, even perl... knowing one of them, you know how to use vi. Likewise, know vi, you know how to use most of these tools (sans visual/modal editing abstraction). Also, it follows the Unix spirit of making small programs (in Vi(m) it can be seen as "a small number of key presses") and composing them…

The so-called "Unix spirit" is itself a rather hilarious mistake from the early days of software engineering, when programmers knew essentially nothing about human/computer interaction and foolishly believed that "efficiency" in a mathematical sense translates to efficient workflows. It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of func…

I think youre being uncharitable to the Unix way. the Unix way is more about having a data standard that all programs can use, rather than a front end that does everything.

yes the everything as a stream of text model didn't really scale, but I don't think that disproves the concept. all of your examples could work as well as, if not better if you standardised a data format and/ or protocol.

The current landscape for software isn't really that monolithic. software of any size implements plugins. If you look back to monolithic software of the 80s where there wasn't any expandability, wasn't things like tool kits or shared libraries. In a sense 'small software' didn't lose. it just moved up and down the stack a bit, and arguably still lives on quite successfully on mobile phones.

Re: GNU nano is my editor of choice (2021)

#206
post #5

There was a time (2006?) when I was getting into linux. I was a big microsofty, due to comfort mostly, and I was shamed into trying Linux. Like most people I went Ubuntu first, but wifi drivers at the time were lacking, and nvidia of yore was certainly not better than nvidia of now. Suffice it to say: I spent a lot of time in the terminal trying to fix things. Nano was my tool of choice because: honestly the initial…

I guess it depends on how you use the system. I have no intention of ever using a Linux as my “main” system. I’m always a visitor on a strange foreign system. I hold my nose, go in, do whatever dirty deed must be done to get it working again. Usually it’s in some docker image, or an old pi used in my closet, maybe a router, or a cloud vm. But regardless it’s never “home”. I don’t have a personal user, I don’t have a…

Git for windows makes a huge deal in its installer about how the default is unchanged for compatibility and how you should pick nano or vsc instead

Re: GNU nano is my editor of choice (2021)

#207
post #39

There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…

I can't think of any program which works like Nano. On the flip side, both man and less provide vim-style navigation. Isn't man the first program we recommend everyone use? On the flip side, there is GNU info, readline, and bash. The latter two of which sport emacs-style navigation by default, but also support vim-style too. Perhaps where we went wrong collectively was indulging the emacs users such that people like…

What doesn’t work like nano? Arrow keys work, backspace deletes, it’s like a GUI text field.

Saving a file is a bit weird but it’s nothing compared to every emacs command being an unlabeled fighting game combo.

Re: GNU nano is my editor of choice (2021)

#208
post #93
post #39

There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…

If you look at how other (console) programs on the system work, Vi(m) is more consistent than Nano. ed, sed, awk, readline, even perl... knowing one of them, you know how to use vi. Likewise, know vi, you know how to use most of these tools (sans visual/modal editing abstraction). Also, it follows the Unix spirit of making small programs (in Vi(m) it can be seen as "a small number of key presses") and composing them…

Beginners don't care about deleting a line, you can press DEL 80 times and get it done. They care about quickly typing something in or changing a config, saving and quitting. Easy to instruct with Nano without having to introduce the concept of mode editing, which is totally foreign to most beginners.

Re: GNU nano is my editor of choice (2021)

#209
post #177
post #39

There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…

Nano default key bindings are not standard either. They are less different than vi from a typical GUI input controls and having a menu at the bottom of the screen help, but they force the user to get used to yet another convention. I was considering at some point to create a patch to nano to have a simple option to switch to more common bindings or even ask the user on the first run about it. But then I discovered th…

+1 for Micro

Re: GNU nano is my editor of choice (2021)

#210
post #148

Earlier quoted context omitted.

> If I want Ctrl+P to paste text across every single application that accepts text and I only have to configure it once in one place, I see that as a win. Ok, so let's say I write a video game. Should my game have reasonable defaults, or should it ask you to go to your system-wide settings and setup all the bindings for my game? For instance, I have a "jump" action. Can I bind it to the spacebar, or should I go check…

> Ok, so let's say I write a video game. Should my game have reasonable defaults, or should it ask you to go to your system-wide settings and setup all the bindings for my game? Note that I specifically mentioned text. We've all agreed on how to write text, we've all agreed on how to read text, why can't we all agree on how we edit text? Text is a universal standard, games are not. Your game can have whatever keybind…

>why can't we all agree on how we edit text

We haven't agreed on a script, keyboard, etc. Given that I don't expect us to agree on how to edit text. What are we going with to base this decision on for starters? Popularity? Utility? something else?

Post reply on HN