17 ms·

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 significan

by p-e-w 4y ago

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. Conventions matter. Don't surprise me. That's literally UX design 101. If a single program sticks out like a sore thumb because every keyboard shortcut suddenly means something different than it does in all other programs installed by default, that program is the problem. 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, and I can only attribute to blatant arrogance from some of the decision makers that it took so long in the first place.

kator 4y ago
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.
- p-e-w 4y ago
  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.
  - chongli 4y ago
    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. $
    - chrisoverzero 4y ago
      Here’s the claim: > [ed] does not have the immediate visual feedback when entering text that even mechanical typewriters have. …and here’s the counterclaim: .s/does not have/does have/g p See how you had to type another command to see the results of this substitution? I don’t think this demonstrates what you want it to.
      - chongli 4y ago
        Typewriters don't have substitution. The immediate visual feedback when entering text in ed is that the keystrokes are echoed to the screen. This occurs regardless of whether you're writing commands or you're in insert mode, such as in this case: 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.
- thanatropism 4y ago
  ed is worth learning. I think the very first thing I learned about computers as a child, at a weird person's behest, was EDLIN.EXE
- danhau 4y ago
  Line / prompt input is not the same as text editing. View it from a average user / UX perspective. Having Ed as the default editor is just as surprising as Vim. Power users and Linux geeks might prefer Vim, rightfully, but neither Vim nor Ed are good defaults. Both mandate having them used before as a prerequesite. You want something that as many people as possible can use out of the box as the default.
- ogogmad 4y ago
  Ed is the right editor for a Unix simulation running inside a ChatGPT session.
tomxor 4y ago
Yup, I have a bunch of vim bindings to give it standard text editing behaviour because it's just too hard to kick muscle memory when you are exposed to it every day through every GUI text field's common behaviour. Jumping between vim and these makes it even harder. I'm talking shift+arrow, ctrl+arrow, ctrl+c, ctrl+v... I know how to do it the vim way and often do, but when you jumping between vim and the rest of the world it just becomes annoying to remember to NOT use those. I find the rest of vim doesn't conflict too much... although occasionally I will accidentally type a c when selecting text outside of vim. Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality. Not all, but not none.
- p-e-w 4y ago
  > Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality. Of course, and I don't see anything unfortunate about it. Pressing buttons to make pixels on a screen change isn't a natural activity, it's a learned one. And commonality simply means there is less to learn before one can become productive, which is 100% a good thing.
moffkalast 4y ago
There are two types of linux developers, those who use nano and those who haven't yet figured out how to quit vim.
elsjaako 4y ago
I'm an enthousiastic vim user. I think everyone who spends a lot if time editing text and who doesn't use vim (or similar) is probably missing out (including the author of this article). I think vim is really good. But I 100% agree that vim is a stupid default. In almost every context it's going to confuse more people than it makes happy.
- pjmlp 4y ago
  I have used VI in and out since introduced to it on Xenix in 1993. Definitely not missing out.
  - giancarlostoro 4y ago
    Neovim is a different beast than vi or vim, definitely suggest looking into it. It's insanely capable, and if major IDE's invested time into supporting it, you wouldn't need to ever choose between Neovim or an IDE, you could just use both together. I think currently VS Code is the only editor that supports Neovim properly, there might be others though. The neat benefit is you get all the editors own plugins + all of Neovims plugins.
    - v3ss0n 4y ago
      Neovide is much better editor that natively supports neovim than vscode. All vim plugins in vscode have conflicts with other extension rendering them useless
    - pjmlp 4y ago
      If stuck with classical UNIX editors, I rather spend my time on Emacs. I know VI well enough to save me when nothing else is available, specially helpful when dealing with servers without root account access, and noexec $HOME, and that is good enough for me.
      - giancarlostoro 4y ago
        If Emacs ever does the headless UI thing I will crawl back to it, in all honesty. I like the idea of consistent editor key bindings across editors and consistently being able to reuse a powerful editor with any IDE.
dig1 4y ago
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 for more complex actions. In Vi(m), almost everything is composable with everything: jumping to the line, deleting line ranges, joining ranges, etc. In Nano (and in Emacs), you end up with tons of Ctrl-keyX-keyB-keyC presses or cursor movements. Example: delete a line - you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. In vi, it is just "dd", no matter where your cursor is. Or, delete 5 lines from the beginning with vi: "gg5dd". Not sure how you can get more unixy than that ;)
- CJefferson 4y ago
  Nowadays, most people are going to know the standard Mac/windows GUI shortcuts before they touch a command line. In my experience, many student's first experience of a command line editor is "git commit", or a similar command, which springs the default editor on them. Learning vim because it just popped up as the default editor is almost impossible.
- arnvidr 4y ago
  >you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. This is not correct, ctrl+k works anywhere on the line?
  - tom_ 4y ago
    It deletes to end of line.
    - danaris 4y ago
      Just tested in GNU nano, version 3.2, the default on Debian Buster, with default settings. Ctrl-K deletes entire line no matter where in the line you use it.
throw0101c 4y ago
Conversely, as multi-decade Unix user, when I type in "vi" I want to get Vi, I do not want Vim starting. If I wanted Vim I would have typed in "vim".
- ogogmad 4y ago
  Why?
  - gnubison 4y ago
    For me personally, the godawful default syntax highlighting is … quite unfortunate
  - throw0101c 4y ago
    As per another reply: all the unneeded crayon colours that are displayed when all I want to do is edit a couple of lines in a plain text file.
Aperocky 4y ago
You don't have to learn vim to craft a git message, most people where I work only know how to exit and they are perfectly fine using vim here or there as prompted. If someone were to learn to use CLI to begin with, I don't mind sprinkling them with some vi. It's UX for those who are already doing CLI, not some people lingering on GUI. Though it's not surprising that someone who believe vim has no benefit whatsoever over other editors have this take, quoth another comment that I replied to in this thread: > I think the idea that Vim is "technically superior" should be challenged as well. I've watched, and participated in, dozens of discussions on text editors, and have never been shown a concrete piece of scientific evidence demonstrating Vim's claimed superiority according to any real-world metric.
- eimrine 4y ago
  How about touchtyping some code in your favourite language but not in linear way? Edit one line here, delete 2 lines there, use some regexp, etc.
giancarlostoro 4y ago
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 than "it forces them to read a manual" alternatively, it might also force them to never use Linux again, which is the opposite of what we all collectively want.
- saagarjha 4y ago
  nano also supports ^S.
- jacob019 4y ago
  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.
1MachineElf 4y ago
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."
- vbezhenar 4y ago
  man does not provide any navigation. It just feeds its output to PAGER which happened to be `less` on your system. On a more bare-bones system man can feed its output to `more`. Which does not provide vim-style navigation, at least its GNU version.
- astrange 4y ago
  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.
MisterTea 4y ago
> 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 world where ed, xi and vi were defaults since the beginning then vi makes sense. This isn't arrogance, its history. Ignoring this part and insisting foreign concepts implemented as defaults to accommodate foreign os users from having to learn to use a new platform is arrogance. Unix has a lost a lot of its heritage to this kind of thinking. Back in the day you learned how to use a computer using manuals: man intro. Today you install an os and blindly bump into walls hoping to learn the os using discoverable ui hints then falling back to google when that fails. Treating the ui as a discoverable manual means ui changes break the manual which angers and frustrates users. See the whole MS ribbon debate.
- andsoitis 4y ago
  Are you arguing that discoverability in user interfaces is bad?
- virtualritz 4y ago
  Your point seems to assume that reading manuals is the 'right' way to learn about working with a system. While it is the preferred way for myself I acknowledge that it is not for a lot of other people. Furthermore you can easily configure any distro today to 'respect history' as much as you desire by changing a few config files. That doesn't change the face that the average person interacting with a *nix OS today will not share this history. Discoverability in UX is a key concept. The people who came up with what you call 'history' simply had no clue about it. Human Computer Interfaces (HCI, what now broadly falls under the term 'UX') was a subject you studied decoupled from the rest of CS (if the university even offered this). People writing tools where oblivious to UX. And the users where the same folks. I would go as far and say that ignoring this and insisting on these modal editors as defaults because 'history' indeed borders on arrogance for this very reason.
  - 4y ago
hk1337 4y ago
I would prefer to use vim over nano personally but as a default, I agree nano is a far better choice.
unnah 4y ago
That is easily solved by configuring other programs to use vi keybindings by default. Shells including bash and zsh can be configured to run in a vi-compatible mode, and so can many other programs - there are even chrome and firefox extensions to enable vi keybindings. Nevertheless, for some reason no one seems to have created a Linux distribution with pure vi input conventions...
emidln 4y ago
The convention on modern *nix is readline/libedit bindings in a shell. These default to emacs-like keybindings that nano ignores. It seems that we have a much stronger case for emacs with the menu enabled than for nano.
_0w8t 4y ago
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 the micro editor and simply have been using that.
- Sebb767 4y ago
  I'm pretty sure that's due to conflicts with default console bindings. That being said, always having a cheat sheet at the bottom makes this mostly a non-issue, even when using something easier as a baseline than vi.
- virtualritz 4y ago
  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.
- just_mc 4y ago
  +1 for Micro
- garciasn 4y ago
  They're standard for beginning of line, end of line, cut line when using bash/zsh; that's already most of the way there. I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.
  - minusf 4y ago
    most shells support both emacs shortcuts and vi style commands so there are at least 2 "standards" fwiw.
vbezhenar 4y ago
ed is the only editor which works like every other console program on the system. Nano does not work like every other program on the system. Neither vi nor nano should be shipped in the base system.
- rahen 4y ago
  This is the reason why ed was originally "the standard editor". Of course, moving from teletypes to terminals made it quite irrelevant as we moved to ex/nvi, but ed still has its advantages. It only requires a kernel and a libc, forget even needing ncurses or termcap. It was running perfectly fine on an 11/40 running V6 on 250kB of memory, so it has stayed insanely resource efficient by today standards. It's not even that bad once the verbose errors are activated (H), and it's still better than using sed or cat > << to recover a partition.
korrt 4y ago
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.
- 3836293648 4y ago
  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
  - glowingly 4y ago
    ^X is …? It totally obviously means shift + 6 + X. Too bad that doesn’t exit the program. Macs in 2022 have an extra ^ on the correct button.
minusf 4y ago
there is no "default editor" in unix systems per se, only installed by default. whatever the user/distribution sets in $EDITOR/$VISUAL is the one being called. vi/vim became "default" on linux distros because it was simply always available while emacs was an optional kitchen sink package and there were no other widely accepted alternatives (like midnight commander's built in editor or nano).

by p-e-w 4y ago

kator 4y ago

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.

p-e-w 4y ago
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.
- chongli 4y ago
  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. $
  - chrisoverzero 4y ago
    Here’s the claim: > [ed] does not have the immediate visual feedback when entering text that even mechanical typewriters have. …and here’s the counterclaim: .s/does not have/does have/g p See how you had to type another command to see the results of this substitution? I don’t think this demonstrates what you want it to.
    - chongli 4y ago
      Typewriters don't have substitution. The immediate visual feedback when entering text in ed is that the keystrokes are echoed to the screen. This occurs regardless of whether you're writing commands or you're in insert mode, such as in this case: 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.
thanatropism 4y ago
ed is worth learning. I think the very first thing I learned about computers as a child, at a weird person's behest, was EDLIN.EXE
danhau 4y ago
Line / prompt input is not the same as text editing. View it from a average user / UX perspective. Having Ed as the default editor is just as surprising as Vim. Power users and Linux geeks might prefer Vim, rightfully, but neither Vim nor Ed are good defaults. Both mandate having them used before as a prerequesite. You want something that as many people as possible can use out of the box as the default.
ogogmad 4y ago
Ed is the right editor for a Unix simulation running inside a ChatGPT session.

tomxor 4y ago

Yup, I have a bunch of vim bindings to give it standard text editing behaviour because it's just too hard to kick muscle memory when you are exposed to it every day through every GUI text field's common behaviour. Jumping between vim and these makes it even harder. I'm talking shift+arrow, ctrl+arrow, ctrl+c, ctrl+v... I know how to do it the vim way and often do, but when you jumping between vim and the rest of the world it just becomes annoying to remember to NOT use those. I find the rest of vim doesn't conflict too much... although occasionally I will accidentally type a c when selecting text outside of vim. Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality. Not all, but not none.

p-e-w 4y ago
> Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality. Of course, and I don't see anything unfortunate about it. Pressing buttons to make pixels on a screen change isn't a natural activity, it's a learned one. And commonality simply means there is less to learn before one can become productive, which is 100% a good thing.

moffkalast 4y ago

There are two types of linux developers, those who use nano and those who haven't yet figured out how to quit vim.

elsjaako 4y ago

I'm an enthousiastic vim user. I think everyone who spends a lot if time editing text and who doesn't use vim (or similar) is probably missing out (including the author of this article). I think vim is really good. But I 100% agree that vim is a stupid default. In almost every context it's going to confuse more people than it makes happy.

pjmlp 4y ago
I have used VI in and out since introduced to it on Xenix in 1993. Definitely not missing out.
- giancarlostoro 4y ago
  Neovim is a different beast than vi or vim, definitely suggest looking into it. It's insanely capable, and if major IDE's invested time into supporting it, you wouldn't need to ever choose between Neovim or an IDE, you could just use both together. I think currently VS Code is the only editor that supports Neovim properly, there might be others though. The neat benefit is you get all the editors own plugins + all of Neovims plugins.
  - v3ss0n 4y ago
    Neovide is much better editor that natively supports neovim than vscode. All vim plugins in vscode have conflicts with other extension rendering them useless
  - pjmlp 4y ago
    If stuck with classical UNIX editors, I rather spend my time on Emacs. I know VI well enough to save me when nothing else is available, specially helpful when dealing with servers without root account access, and noexec $HOME, and that is good enough for me.
    - giancarlostoro 4y ago
      If Emacs ever does the headless UI thing I will crawl back to it, in all honesty. I like the idea of consistent editor key bindings across editors and consistently being able to reuse a powerful editor with any IDE.

dig1 4y ago

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 for more complex actions. In Vi(m), almost everything is composable with everything: jumping to the line, deleting line ranges, joining ranges, etc. In Nano (and in Emacs), you end up with tons of Ctrl-keyX-keyB-keyC presses or cursor movements. Example: delete a line - you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. In vi, it is just "dd", no matter where your cursor is. Or, delete 5 lines from the beginning with vi: "gg5dd". Not sure how you can get more unixy than that ;)

CJefferson 4y ago
Nowadays, most people are going to know the standard Mac/windows GUI shortcuts before they touch a command line. In my experience, many student's first experience of a command line editor is "git commit", or a similar command, which springs the default editor on them. Learning vim because it just popped up as the default editor is almost impossible.
arnvidr 4y ago
>you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. This is not correct, ctrl+k works anywhere on the line?
- tom_ 4y ago
  It deletes to end of line.
  - danaris 4y ago
    Just tested in GNU nano, version 3.2, the default on Debian Buster, with default settings. Ctrl-K deletes entire line no matter where in the line you use it.

throw0101c 4y ago

Conversely, as multi-decade Unix user, when I type in "vi" I want to get Vi, I do not want Vim starting. If I wanted Vim I would have typed in "vim".

ogogmad 4y ago
Why?
- gnubison 4y ago
  For me personally, the godawful default syntax highlighting is … quite unfortunate
- throw0101c 4y ago
  As per another reply: all the unneeded crayon colours that are displayed when all I want to do is edit a couple of lines in a plain text file.

Aperocky 4y ago

You don't have to learn vim to craft a git message, most people where I work only know how to exit and they are perfectly fine using vim here or there as prompted. If someone were to learn to use CLI to begin with, I don't mind sprinkling them with some vi. It's UX for those who are already doing CLI, not some people lingering on GUI. Though it's not surprising that someone who believe vim has no benefit whatsoever over other editors have this take, quoth another comment that I replied to in this thread: > I think the idea that Vim is "technically superior" should be challenged as well. I've watched, and participated in, dozens of discussions on text editors, and have never been shown a concrete piece of scientific evidence demonstrating Vim's claimed superiority according to any real-world metric.

eimrine 4y ago
How about touchtyping some code in your favourite language but not in linear way? Edit one line here, delete 2 lines there, use some regexp, etc.

giancarlostoro 4y ago

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 than "it forces them to read a manual" alternatively, it might also force them to never use Linux again, which is the opposite of what we all collectively want.

saagarjha 4y ago
nano also supports ^S.
jacob019 4y ago
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.

1MachineElf 4y ago

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."

vbezhenar 4y ago
man does not provide any navigation. It just feeds its output to PAGER which happened to be `less` on your system. On a more bare-bones system man can feed its output to `more`. Which does not provide vim-style navigation, at least its GNU version.
astrange 4y ago
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.

MisterTea 4y ago

> 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 world where ed, xi and vi were defaults since the beginning then vi makes sense. This isn't arrogance, its history. Ignoring this part and insisting foreign concepts implemented as defaults to accommodate foreign os users from having to learn to use a new platform is arrogance. Unix has a lost a lot of its heritage to this kind of thinking. Back in the day you learned how to use a computer using manuals: man intro. Today you install an os and blindly bump into walls hoping to learn the os using discoverable ui hints then falling back to google when that fails. Treating the ui as a discoverable manual means ui changes break the manual which angers and frustrates users. See the whole MS ribbon debate.

andsoitis 4y ago
Are you arguing that discoverability in user interfaces is bad?
virtualritz 4y ago
Your point seems to assume that reading manuals is the 'right' way to learn about working with a system. While it is the preferred way for myself I acknowledge that it is not for a lot of other people. Furthermore you can easily configure any distro today to 'respect history' as much as you desire by changing a few config files. That doesn't change the face that the average person interacting with a *nix OS today will not share this history. Discoverability in UX is a key concept. The people who came up with what you call 'history' simply had no clue about it. Human Computer Interfaces (HCI, what now broadly falls under the term 'UX') was a subject you studied decoupled from the rest of CS (if the university even offered this). People writing tools where oblivious to UX. And the users where the same folks. I would go as far and say that ignoring this and insisting on these modal editors as defaults because 'history' indeed borders on arrogance for this very reason.
- 4y ago

hk1337 4y ago

I would prefer to use vim over nano personally but as a default, I agree nano is a far better choice.

unnah 4y ago

That is easily solved by configuring other programs to use vi keybindings by default. Shells including bash and zsh can be configured to run in a vi-compatible mode, and so can many other programs - there are even chrome and firefox extensions to enable vi keybindings. Nevertheless, for some reason no one seems to have created a Linux distribution with pure vi input conventions...

emidln 4y ago

The convention on modern *nix is readline/libedit bindings in a shell. These default to emacs-like keybindings that nano ignores. It seems that we have a much stronger case for emacs with the menu enabled than for nano.

_0w8t 4y ago

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 the micro editor and simply have been using that.

Sebb767 4y ago
I'm pretty sure that's due to conflicts with default console bindings. That being said, always having a cheat sheet at the bottom makes this mostly a non-issue, even when using something easier as a baseline than vi.
virtualritz 4y ago
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.
just_mc 4y ago
+1 for Micro
garciasn 4y ago
They're standard for beginning of line, end of line, cut line when using bash/zsh; that's already most of the way there. I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.
- minusf 4y ago
  most shells support both emacs shortcuts and vi style commands so there are at least 2 "standards" fwiw.

vbezhenar 4y ago

ed is the only editor which works like every other console program on the system. Nano does not work like every other program on the system. Neither vi nor nano should be shipped in the base system.

rahen 4y ago
This is the reason why ed was originally "the standard editor". Of course, moving from teletypes to terminals made it quite irrelevant as we moved to ex/nvi, but ed still has its advantages. It only requires a kernel and a libc, forget even needing ncurses or termcap. It was running perfectly fine on an 11/40 running V6 on 250kB of memory, so it has stayed insanely resource efficient by today standards. It's not even that bad once the verbose errors are activated (H), and it's still better than using sed or cat > << to recover a partition.

korrt 4y ago

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.

3836293648 4y ago
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
- glowingly 4y ago
  ^X is …? It totally obviously means shift + 6 + X. Too bad that doesn’t exit the program. Macs in 2022 have an extra ^ on the correct button.

minusf 4y ago

there is no "default editor" in unix systems per se, only installed by default. whatever the user/distribution sets in $EDITOR/$VISUAL is the one being called. vi/vim became "default" on linux distros because it was simply always available while emacs was an optional kitchen sink package and there were no other widely accepted alternatives (like midnight commander's built in editor or nano).