Live data from Hacker News

GNU nano is my editor of choice (2021)

ariadne.space

161–170 of 303 posts

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

#161
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…

Personally, I'd prefer if "ne" was the default, or similar. I love nano, I've installed it many times just so I can do quick one line edits, since I have the muscle memory for nano, but something like "ne" uses standard key bindings that users of other OS' are used to like ctrl + s which some Linux neckbeards will scoff at, but you gotta understand, there is no benefit to force emacs, vim or nano on someone, other th…

Who's forcing? People are just enthusiastic about vim because of the productivity bump when it clicks. I thought it was fun to learn, and didn't take long at all. I went through vimtutor, that was about it.

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

#162

Using those kind of Unix tools is like having a time travel machine to understand what kind of mistakes you should never do when Iyou design a software. Not having system wide keyboard shortcuts is one of them: vim, emacs, nano etc all have a different shortcut to quit the app Worse still, every software invents his own configuration format. Thinking that being ultra configurable is a good excuse for not doing the ri…

Is is typically the case that there are system-wide in most popular GUIs, like GNOME and KDE. It's even the case in something like i3 or sway. In a GUI environment, you get GUI-wide shortcut keys.

On the command-line, there is no GUI. Yet there are still a number of system-wide shortcuts, but things are a little different, because you are interacting with text. And often, you're only interacting with one program at a time. In most places, ^C, ^D, ^I, and ^Z work the same way. In Bash and other shells and programs that use readline, several Emacs-style shortcuts also work the same, notably ^A, ^E, and ^K.

There are probably others, but you'll notice that few of them have anything to do with copy and paste, because that is often meaningless between programs without a GUI to show multiple programs at once, in which case the GUI, not the CLI, would implement something. There just aren't that many needs for more shortcuts when you have only one program in front of you.

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

#163
post #153

Earlier quoted context omitted.

Sorry for the communication style, that's noted. I meant to communicate a point though. My point is that I don't want vim to copy with "Cmd + V" (I want the vim bindings there), and maybe I want to reuse "Cmd + V" in Blender for something more important than "paste" (assuming that "pasting" is not really a concept in Blender, I don't know). But still I want "Cmd + V" in Word and in my e-mail client. How do you set th…

You can override things like paste system-wide or you can customize it for a particular app.

Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults.

Even for the obvious example of the text editor, where "everybody wants Ctrl+P to paste", where I precisely don't want that in vim and emacs.

That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves (instead of reusing something I defined system-wide for different apps). Because the app developer knows their app better. If I don't like it, I can customize it or just not use it. "Don't use vim if you want it to behave like Word", in some sense. Both are great, but different. And that's fine.

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

#164
There's a reason I've always removed nano on every system I administer, and have done so for decades: when I first learned of nano, I also learned that it can corrupt configuration files where line breaks are significant by hard-wrapping long lines, unless you're very careful to always use "nano -w" instead of just "nano". I believe that this default has changed in a recent version of nano, and even before that some Linux distributions shipped with it set to not hard-wrap by default on a global configuration file, but it's still an unnecessary risk (unless you're really sure that the nano version is recent enough to have the new default, and that you'll never ssh to a machine running an older version of nano).

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

#165
post #153

Earlier quoted context omitted.

Sadly, you chose sarcastic trolling instead of clearly communicating your point. However, it seems like you're assuming system-wide keyboard shortcuts and consistent defaults means you can't change anything. On macOS, you can change the keyboard shortcuts, including idiosyncratic ones, of (almost?) any application, certainly any pure Cocoa one. I have Word set up so that CmdV pastes unformatted, for example, and I ha…

Sorry for the communication style, that's noted. I meant to communicate a point though. My point is that I don't want vim to copy with "Cmd + V" (I want the vim bindings there), and maybe I want to reuse "Cmd + V" in Blender for something more important than "paste" (assuming that "pasting" is not really a concept in Blender, I don't know). But still I want "Cmd + V" in Word and in my e-mail client. How do you set th…

They're not enforced by technical means, usually, but Apple HIG are fairly highly regarded by developers and users alike.

I only do UI programming in wxWidgets so I can't speak for other developer workflows. When I create a menu system, if I don't include accelerators manually, the system-appropriate ones are automatically added for certain things. Additionally, wxWidgets automatically moves Windows/Linux "standard" menu items to macOS-specific locations (e.g., Quit and About menu items), if and only if they're in the pertinent menus at the time they're added to the menu bar. If I add the File menu to the menu bar, and then add "E&xit" to the file menu, it still shows in the File menu.

So, in my experience, it's a strong default, but it isn't constraining; you can easily override that behavior when necessary.

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

#166
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?

Because there are some extremely different ways of editing text out there. As you mention, vim and emacs are extremely different from Word, though extremely popular. There are certainly many more examples, but I believe those 3 are enough to say that we most definitely have not all agreed on how to edit text.

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

#167
post #105
post #73

Earlier quoted context omitted.

> We have a less powerful tool because we want to attract newbies That's exactly it. The modern metrics for anything to be successful is the number of people using it, even if they are completely useless because they did not put any effort into learning the basics. In this case, it would be essentially "ESC", "i" and ":wq". But that's waaaay too hard. No wonder everybody ships a full rootfs in a container for every s…

eheh, so much this. I was about to comment in a less sarcastic way but essentially the same thing. I mean, we'll be just fine installing vim and make it the default as needed, I'm not so sure about those raised with the "it has to be easy" mantra.

> I was about to comment in a less sarcastic way

Yeah sorry, I really did not mean to sound aggressive, just trying to share my point. Communication is hard :-).

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

#168
post #55
post #47

Earlier quoted context omitted.

By that logic we should just make "ed" the default editor. It's more like every other line oriented CLI interface element in the system than Nano is.

Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.

Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have.

What do you mean?

    $ ed
    i
    Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
    .
    .s/not useful/useful/g
    p
    Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
    .s/does not have/does have/g
    p
    Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is useful for writing, because it does have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
    w ed_is_useful.txt
    389
    q
    $ cat ed_is_useful.txt 
    Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is useful for writing, because it does have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
    $

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

#169
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 yourself could eventually say "Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works."

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

#170
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 machines that I use frequently, and just load the folder into my IDE and edit files in my IDE. VIM was designed in a very different era when terminals were small. An IDE gives me an integrated debugger, code completion, code formatting, project management(very useful for hierarchical projects) and integration with tools like VCS, Testing frameworks etc. I still don't understand people who use vim(or nano) as their primary editor.

Post reply on HN