Hacker News Reader

Comment by p-e-w | Hacker News Reader

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.

View on HN

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.

I have used VI in and out since introduced to it on Xenix in 1993.

Definitely not missing out.

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.

Neovide is much better editor that natively supports neovim than vscode. All vim plugins in vscode have conflicts with other extension rendering them useless

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.

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.

What does it mean for an IDE to support neovim?

it probably means to run actual instance of neovim and use it as a backend for current editor's content.

Except you get features of both editors, so IntelliJ would still have their auto complete intellisense features, and Neovim key bindings would still work, and Neovim plugins as well.

I know I'm not going to convince everyone, and I know that there are other advanced options that compete (people tell me I'm missing out because I don't use an IDE with all the auto complete stuff).

But I see a lot of people using a text editor that's basically notepad, possibly with syntax highlighting. For an occasional edit that's fine, but if you regularly spend more than an hour editing a file, you would benefit from more features.

Vim has a lot if features I don't know, so I think I'm also missing out (until I learn those features). It takes investment of time to learn an advanced tool.

I'm curious, what text editor do you use?

IDEs of course, and if stuck on UNIX without an IDE, either Emacs (muscle memory goes back to XEmacs glory days) or VSCode.

Pure text editor, Notepad++.

What do you think an IDE has that a proficient vim user is lacking?

Which vim? I prefer neovim personally, but it is not my default editor. I want JetBrains to get off their butts and implement first-party support for Neovim. They would be able to fully ditch their awful vim emulator, and I'm honestly astounded they still have not done a neovim first party plugin yet, or anyone for that matter (last I looked anyway). It would solidify vim for me permanently, being able to pop it into an IDE, and going to a command line and having the same editing experiences (minus IDE witchcraft right).

I think vim or neovim are both fine. The only reason I would caution against elvis is lack of Unicode support. They all give you most of the same interface.

I'm not referring to Elvis though, at least I don't think so:

https://github.com/neovim/neovim/wiki/UI-architecture

I've tried to like neovim but plain vi works best for me. I've tried to like nano too.

Since you brought up JetBrains, I use no products made by them, at all, any more. I use Eclipse and I don't use a vi plugin in Eclipse.

My habit is if in bash, use vi, if in an IDE (or otherwise at my Ubuntu or Windows (work...I know) desktop), use a regular type of editor.

If I were young and never worked on old Korn shell systems or other old UNIX systems I'd probably not have learned vi and would be a nano user in the shell today.

Summary, in my brain, shell == vi, IDE\|desktop == regular editor

> Since you brought up JetBrains, I use no products made by them, at all, any more.

Just curious. Why?

“because it’s not mainstream enough”

sounds like a skill issue

> [...] everyone [...] who doesn't use vim (or similar) is probably missing out (including the author of this article)

Did you read the article? The author used both emacs and vim. Quote:

"I don’t like either of them, for differing reasons: modal editing doesn’t really fit my mental model of how an editor should work, [...]"

I don't get how people who like modal editing can't accept that other people don't.

From my experience with editor debates this weirdly seems to be much more common than the reverse.

De gustibus non est disputandum.

> I don't get how people who like modal editing can't accept that other people don't.

Hi. I like modal editing and kind of can't accept that other people don't.

I think they just haven't really tried, you know? In my view, it isn't a subjective matter of preference, rather I consider modal editing to be objectively superior: we have the whole keyboard at our disposal to enter commands and manipulate the text, not just tricky key combinations.

Sometimes the objection to modal editing is that you need to keep an eye on which mode you're in, but in my experience. If you're doing it right, you're always in normal mode, unless inserting text. When you finish inserting text, you immediately switch to normal mode.

There, I probably haven't convinced you nor anyone else, but I'm sure all the vim users are nodding along ;)

There are only two kinds of non-modal editors.

1. A useless, primitive thing in which every single keystroke inserts a character or performs an edit action, and then returns to the initial state. Typically found in the simplest edit controls offered by a windowing UI, or very simple command line editors.

2. A command-oriented editor in which every action is performed by typing a line of input, terminated by Enter to execute the command. E.g. ed, almost. This is always in a command mode, which accumulates characters until Enter, executes, and returns to command mode. If there is a mode for appending lines until . (dot) is entered on a line by itself, then that is modal.

Everything else is modal.

I just fired up Nano. I made some changes and quit with Ctrl-X. Lo and behold, I was dropped into a mode in which I had to type y or n to save or not. Note that the usual action of these keys is to insert the characters y or n into the buffer. I issued y, and was dropped into another mode in which the characters I typed didn't insert into the buffer, but into a prompt asking for the file name.

Suggesting that nano and vim are both "modal editors" because nano has some confirmation dialogs is not a deep insight, it's just pedantry. And it ignores the entire reason why you'd describe an editor as modal: that changing modes is integral to the editing experience. You can't change modes in nano to make editing more efficient.

That may be the entire reason you would describe an editor as modal, but those who don't like modal editors have a different reason: they claim that they are confused by stateful behavior: that the same inputs cause different things to happen depending on what state the program is in. Usually, plenty of modal behaviors can be identified in whatever alternative they endorse. The depth of that insight is what it is.

> From my experience with editor debates this weirdly seems to be much more common than the reverse.

This reads like confirmation bias to me, and I would argue the inverse.

Otherwise, I agree with you. It’s ok that people have their own preferences.

I get the feeling he occasionally used it, but not intensely for a long time.

Modal editing isn't something that comes naturally. You have to train yourself to use it. I believe everyone can learn to do it as if it's natural.

I learned how to use vi/vim a long time ago, and if you put me in the same position now I probably wouldn't learn to use it. It was a lot of effort. Having done it, I'm really glad I did, but it's hard to see how nice it is before you're put in the effort.

I also like dancing, and often a teacher will make you move in a way that doesn't feel natural. Months later, once you've got the hang of it, it makes total sense that that's the better way. It becomes natural. Driving with a stick shift didn't feel natural at first, now I miss the clutch when it's not there.

Sometimes the "unnatural" way is better. I'm guessing the same is true for the way chefs cut vegetables, or classical guitarists hold their guitar.

I won't fault anyone for not using vim, I understand it's a tradeoff and not everyone wants to put in the effort. And if you don't spend a lot of time editing text, it's not worth it.

Just to possibly annoy even more people: if you spend a lot of time on a keyboard, and you can't touch-type, I also feel you're missing out. (That wasn't natural for me at first either).

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 ;)

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.

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

It deletes to end of line.

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.

It's cutfromcursor in nanorc if you want the other behavior.

https://nano-editor.org/dist/latest/nanorc.5.html

I believe ctrl+k cuts the line. ctrl+u pastes the line, yea?

Well, yes. I was just matching the wording of the comment I was replying to.

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 functionality integration, not functionality separation. Email and calendars are often used together, that's why they belong in the same program. Similarly, it makes sense for a programmer's editor to have an integrated terminal, and for a web browser to have an integrated bookmark manager.

"Small programs" is a bad idea that happens to sound like a good one. We don't really need to debate this, as reality has settled that debate long ago. Software serves people, not ideals of rational optimality. And default software must serve the greatest possible number of people well, else it's the wrong default.

Integration does not presuppose hard coupling. Different components can integrate and coordinate through standards.

I would argue that having one big app is the one of the worst methods of integration.

> Different components can integrate and coordinate through standards.

We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks.

There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands.

Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end.

[1] https://www.nushell.sh/

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.

Unix efficiency is all about saving time and paper on a teletype. It just happens to have side benefits on modern computers.

> It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation.

Yes, so much integration that despite JetBrains IDE functionality being first-class, we have still seen the rise of LSP over the last few years.

That's more like the Unix philosophy, not less.

And that's not even to mention that small, composable programs and libraries are NOT incompatible with integration. In fact, they help it.

LSP took off because it was designed and heavily promoted by one of the most powerful technology corporations on the planet, who already had the ears of tens of millions of developers.

The number of proposed "standards" for solving similar problems over the years that have failed or even been completely ignored is legion. LSP is one of only a handful of software integration standards that have ever found widespread adoption. Meanwhile, there are hundreds if not thousands of integration problems where no standard is in sight.

This universal vision where micro-programs process and pass around standardized data is never going to happen, except on platforms that are completely controlled by a single vendor (see Apple).

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.

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.

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.

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.

+1 for Micro

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.

most shells support both emacs shortcuts and vi style commands so there are at least 2 "standards" fwiw.

I think that's why I've never shifted from vi to nano, it appears to be a regular editor but ignores all common key bindings, ctrls+s doesn't save, ctrl+f doesn't find, ctrl+h doesn't replace, etc.

I just fired up Nano on Ubuntu 18 installation.

When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt.

Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the cursor (possibly after climbing to the previous line, if the cursor is at the start of a line), it is objectively, positively wrong.

You can distinguish Ctrl-H from backspace in a GUI system where you get detailed keyboard events. Nano has to work in a terminal.

You're right ctrl+s works, I tried it, I always thought it had to be ctrl+o since that's what the bottom panel shows. I was encouraged so I highlighted some text then tried ctlr+c and ctrl+v, unless I hit a wrong key somewhere, it didn't work.

Ctrl-C and Ctrl-V are not common keybindings, unless we are talking about the Microsoft Windows environment, and graphical environments aped after it.

In the GNU/Linux environment, the standard keybindings are the Emacs-derived ones. Ctrl-A to go to the start of the line, Ctrl-E to jump to the end, ... pasting is called "yank" and mapped to Ctrl-Y.

Your point stands since GNU Nano doesn't stick to these either.

Ctrl-C is interrupt in the TTY environment. This is so entrenched that programs which obtain Ctrl-C as ordinary input rather than a SIGINT signal still use it for interruption. E.g. in Vim, we can use Ctrl-C to interrupt long operations.

Ctrl-V is entrenched as a "verbatim" key: insert the following character literally, even if it is a control character.

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.

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

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.

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

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.

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.

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.

nano also supports ^S.

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.

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

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.

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.

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

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.

Ed is the right editor for a Unix simulation running inside a ChatGPT session.

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

Why?

For me personally, the godawful default syntax highlighting is … quite unfortunate

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.

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.

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.

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

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

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

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.

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.

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

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

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

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

Are you arguing that discoverability in user interfaces is bad?

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.

> The people who came up with what you call 'history' simply had no clue about it.

Saying they didn't have a clue is both disingenuous to those who worked hard on these problems and flat out wrong.

These programs were written for text terminals running over links who's speed was measured in hundreds or thousands of bits per second. The UI had to be as simple and efficient as possible to enable a decent UX over such slow lines. The UI was sacrificed for the UX. Of course after networks got faster these editors weren't necessary but guess what, they were understood, worked and there by default. And they still are. I see no issue with this and learning vi is actually simple once you RTFM.

Back in the day you'd write your own driver where need be, and compiled almost everything. I'm quite happy to not be back in the day and will take nano for editing a config file over writing C in Vim.

Reply on news.ycombinator.com