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.

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.

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

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

Just curious. Why?

Definitely not missing out.

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?

Pure text editor, Notepad++.

The neat benefit is you get all the editors own plugins + all of Neovims plugins.

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.

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.

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

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

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.

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.

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

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.

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

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/

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.

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.

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

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.

This is not correct, ctrl+k works anywhere on the line?

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

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

I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.

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.

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.

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.

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.

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

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

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

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

    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.

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.

If I wanted Vim I would have typed in "vim".

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.

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

Nevertheless, for some reason no one seems to have created a Linux distribution with pure vi input conventions...

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.

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.

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.

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.

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.

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 learning curve of linux and a modal text editor was far too much.

that said: when I was later shamed into using vi/vim instead of nano.. after my initial hesitation (and a few rounds on vimtutor) I was as confident as I was on nano... what's more, I was "unlocked" and started learning new and faster ways to move.

Being able to replay my last action with "." was nice, and lead me to learn even more native movements.

My watershed moment came when I had to delete a leading series of characters in a file of I think 500 lines.. Not enough to say it's impossible but a real chore.

Nano would not help me in such a situation: but vim did it with no complaints; all I needed to know was the incantation.

I feel like nano shipping as the default editor is a step-back. We have a less powerful tool because we want to attract newbies, but it's the same mistake microsoft makes; When I was into microsoft tooling I had no idea how handicapped I was, the learning curve always had a stop point: everything beyond it was impossible.

I will always be thankful I learned linux in a time where the hand-rails were starting to come up, but that we still used powerful and expressive tools instead of being jailed to the opaque and inflexible systems that have come to dominate for the sake of convenience.

Perhaps, but your experience sounds like a good blueprint for what new terminal users might want. Start with nano move to more powerful tools when you need them.

Those who need more know how to install Notepad++, UltraEdit or Sublime.

less powerful doesn't mean worse if you aren't using the features. It just makes it harder to use.

I was extremely resistant to learn new things when I thought my current way of working was perfectly fine.

It’s only retrospectively that I realise how limited I was.

I've tried to get into vi and emacs but I honestly never found a good use case for them, even as a developer. When I edit files, the changes are usually very small and I spent most time thinking about what to change. The time it takes to execute that change is negligible. If I need to process large files, those are usually in some kind format that can be manipulated with other tools much more easily. And when it comes to programming, modern IDEs are far superior.

I don't doubt that you can be very productive with these editors but the "it's more powerful" argument always seems to mean "look how I fast I can manipulate large unstructured text files with some keyboard shortcuts magic", which is irrelevant to me.

It’s not the OS’ job to lecture users about their tools of choice. The Web is full of “vim is the dog’s bollocks” articles, if anyone has a modicum of interest to look at more complex tools.

Now, we have to just set EDITOR in the dotfiles for each new student we get starting their MSc project. They have 6 months to do quantum chemistry stuff, not winning flame wars about whose editor is best. And they have already a lot of inane idiosyncrasies to learn in R and the usual Python libraries.

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 single executable they make... if learning how to quit vim is too hard, who would want to learn about packaging?

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.

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

To me, it's perfectly fine to set nano as a default for a distro targeting beginners, but it is also perfectly fine to set vim as a default and say: "if using vim to change the default editor is too hard for you, then you are not the target audience".

Nano can do regexp search and replace. I think the problem with nano is the menu in the bottom because it makes people think that it's the only things it can do when in fact it's really powerful.

C-c didn’t work, Ctrl+Alt+F2 didn’t work, ssh didn’t work because sshd is not up yet, even VM power cycling button was stuck and didn’t work. Maybe a custom VNC client could have worked. I think I ended up rebooting the host once, just to get out of vi. Second time I just changed locales.

nano by default is good.

You could regexp replace all '^[a-z]{4}' (or whatever) with ''. Alternatively you could select area and execute '|sed <whatever>' or '|cut <whatever>'. Advantage: you use the tools you're already familiar with.

> I feel like nano shipping as the default editor is a step-back

Not sure why you'd say it's a step back after giving a very valid reason for why it's a step forward.

Editing configuration files as a beginner can be frustrating on its own. The added friction of fighting with your editor when you just want to change a single line is not something I wanted to deal with.

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 home directory with my own config files. My user is “pi” or “root” or something to that effect. I have been logged in there before, but each time I need to find my way around from scratch. All I need to do is edit some files and get the hell out. And nano is just perfect for it.

Perhaps the worst use of vi-as-a-default is in Cygwin (used to run git on windows by some people still) where vi is popped up to let windows users fill in a git commit message. Fantastic UX. I don’t blame Cygwin for it, but git-for-windows could ship with a different default (even notepad would have been better).

Tbh I don’t know why you’d want a bash for it to begin with. The only thing I miss in other shells (cmd/PS) is that you can’t make shell aliases in git.

But of course you want bash with git. PS and cmd are just painful to use

Don't get me wrong, that feature alone is powerful enough to choose vim as your editor of choice, but... There is no reason whatsoever why you couldn't have an editor with 2022's standards of UX and newbie friendliness that makes use of the same idea; it just hasn't happened.

Even when modern editors adapt vim functionality as a plugin, they just replicate the original design choices. Esc to escape insertion mode is clearly a stupid choice in a modern keyboard setup, but we keep it as a default; we just haven't moved past the original decision.

Has anyone heard of a (serious / developed) effort to create such a product?

The closest I can think of is Helix.

> Esc to escape insertion mode is clearly a stupid choice in a modern keyboard setup, but we keep it as a default; we just haven't moved past the original decision.

Nitpicking a bit, but you can also escape insert mode with Ctrl+[ and alt+any normal mode keybinding. I tend to use alt+h/j/k/l but nothing prevents you from doing for e.g. alt+u to escape insert mode while undoing the previous action.

I’ve never used a distribution that includes nano, but not also some variety of vi and/or emacs. And there’s no “favorite”/“default” binding in terminal.

There are defaults in the GUI, however those are almost exclusively Kate or gEdit. And new users probably use those far more frequently as their first editor.

The only qualifier I can figure for nano being a default is the number of tutorials/guides that use it.

There is.

There is the EDITOR environment variable and the alternatives editor. They will be used when a program triggers an interaction that uses a text editor (e.g., mutt, git and more) instead of manually opening an editor yourself.

There are also distributions that only ship with a minimal set of editors, forcing you to install different ones. This might also be considered a "default" editor by lots of people.

edit: if you consider a "default binding" only one for manually opening a text file, then you are right, but I don't think that is what people talk about when referencing a "default text editor"

whatever the root users $EDITOR variable is set to (and any subsequent created user) is the default.

vi/vim wasn't even installed last time I installed ubuntu minimal: but nano was.

It’s “Suffice it to say…”

[...]

> I feel like nano shipping as the default editor is a step-back

Make up your mind about nano being the easy way in, or just admit that you like the vim gatekeeping?

i have yet to find someone doing complex editing stuff in vim that i cant do (i.e. with the same effort or less) in nano. Unironically.

Or replace a selection with the output from a call to 'cut'.

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 right thing by default is another big one. Syntax highlighting should just work, not only sort of work when you learn a configuration syntax and install little known third party packages

My preference is to start with a minimalistic system that works on most platforms, and where I can install what I want. If I wanted a system with "sane defaults from someone else's point of view" and working only on a handful of platforms, I would use macOS.

System-wide does not imply unconfigurable, it just means that all programs derive some of their behavior from an external source.

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 in your system settings what you have assigned to "jump"? What if you have not assigned anything to "jump", should I choose a free shortcut somehow (say using the first available from a list like [spacebar, j, right-shift]) or should I ask the player to go setup the bindings first?

Say people are happy having exactly one configuration for all their programs. What if my game has special controls, and instead of using "awsd" to move, I would like to use "qweasd", but "q" is generally assigned to "quit". Should I give up on having a reasonable UX using the keyboard (because the system-wide shortcuts don't work for my game) and sell my game with an external controller then?

That's the whole thing with standards. It's perfect if you want to do exactly what the standard specifies. It's terrible if you don't. Freedom generally doesn't go well with standard, and somehow it feels like a tradeoff: macOS has a better user experience than linux, at the cost of some freedom. And that's perfectly fine IMO: I don't expect macOS to give me more freedom, or Linux to give me a macOS UX. I just choose between them.

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 keybindings it deems sane but the second I click on a textbox to enter my name I expect my keybindings to work because I'm no longer in the game's context, I'm inside a text context.

Using the user's preferences is a sane default but it's just that - a default, capable of being altered. That default might not be the most intuitive for your specific application and you can let the user know there's a better alternative but at least that default doesn't completely paralyze the user until they've taken the time to learn your specific way of doing things, as is the case with Vim.

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?

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.

Key word here being _different_. Different should not be the default. That does not mean we should all be forced to edit text the same way, it just means that the most widely used way of editing text should be the default.

For the most part we have agreed on what the standard way of editing text is in GUI's. nano has its quirks but at least it follows the most widely accepted standard - if you're inside a text editor and start typing text, the text gets appended and magical things happen to your text only after you press a combination of keys.

You didn't actually provide an argument against having a sane set of defaults with the option to configure them later.

> As an artist, you can choose to make the kind of music most people want to hear in a night club, or make the kind of music you, as a musician, like. And accept that maybe that's not for the majority.

"For art" is a non-answer when it comes to UX - being "artsy" is almost always terrible UX, including in this particular manner of keyboard shortcuts - very, very few people want "artsy" shortcuts, almost everyone wants familiar defaults, and some people want to then configure the bindings after they've gotten used to the tool a bit.

Art is, by definition, about creativity and originality, which is almost the polar opposite of good UX, which is standardization and conformity.

Making a video game with some esoteric control scheme? Fine, go crazy with your input design, people may love it - that is an artistic matter, less so a UX matter. Making an actual tool that people need to use to get work done? That's a UX problem, and your job is to design the tool to be as painless to use as possible, not to be creative, because your creative desire will, unless controlled very carefully, directly lead to pain and frustration of your users.

I am not convinced that it is possible to come up with a generic sane set of defaults for all apps in a way that would solve the problem of VIM being fundamentally different. Everybody wants sane defaults, I don't see the debate there.

> "For art" is a non-answer when it comes to UX

Not my point at all (but that's on me). My point was that "for the majority" is not necessarily the right answer when your system (Linux) is used by a minority.

Especially because the easiest example (text editors) has huge, obvious counter-examples showing that there is no universal set of defaults to edit text on Linux (nano vs emacs vs vim).

That's not a problem that needs to be solved. "Generic sane set of defaults" excludes vim as an editor by definition.

In terms of which editor should be used by default, vim should not be the default[1].

In terms of keybinding defaults for vim, because vim's modal editing model is so unique, it's totally fine for a universal keybinding system to not trivially integrate with it - just like it's totally fine for libc to not contain every single variant of a memory allocation or string copy function. No abstraction is universal.

> for all apps

Again, a red herring - there's no reason why any programming system has to work "for all the things".

> My point was that "for the majority" is not necessarily the right answer when your system (Linux) is used by a minority.

This is such a vague statement as to be meaningless. How, specifically, are you claiming that Linux users are different from Windows/MacOS users that a different system is needed?

Moreover, given how obviously the design strategy of "sane consistent (but configurable) defaults" fits in to human cognition, I'm very curious as to why you think it somehow doesn't apply to Linux users. If your answer is "they're more technical" - that's irrelevant. Power users and programmers also want user interfaces for new tools to be maximally sane and consistent during their initial learning period, and the configurable afterward. This isn't a Windows/MacOS/Linux thing, this is a human thing.

> Especially because the easiest example (text editors) has huge, obvious counter-examples showing that there is no universal set of defaults to edit text on Linux (nano vs emacs vs vim).

That's because they're obviously not counter-examples. vim and emacs are not the default editor on the majority of user-facing Linux boxes (graphical Ubuntu) - they have to be picked and learned, and most non-technical users that try quit very fast. Those are not even candidates for a set of defaults - those are highly user-hostile specialized programming tools. You know what the default text editor is in Ubuntu? Gedit. Not vim or emacs, not nano or even pico. Gedit. That's the default, and its behavior very closely matches the behavior of the default text editors on Windows and macOS.

Moreover, there is a set of defaults, without a name, that corresponds roughly to what you get in a text field in Firefox. Left-click to place cursor, right-click for context menu, drag-left-click to select region, ctrl-c to copy, etc. You get this behavior in Libreoffice, Gedit, Firefox, Blender, GIMP, various file explorers, random GTK+Qt widgets, and basically everything else except vim, emacs, nano, and the terminal. That is the standard.

As further evidence: the number of people who know how to use ctrl+z/x/c/v (and other standard text-editing shortcuts) outnumbers the combined amount of people who know how to use vim and emacs, by orders of magnitude.

So, yes, there is a set of defaults on Linux. Vim, Emacs, and Nano are not it.

[1] https://news.ycombinator.com/item?id=34161694

If you mean on Ubuntu, then sure. Ubuntu's target audience is essentially people who want an alternative to Windows/macOS. Not people who want the freedom to use their preferred tools. You think systemd is a sane default and advanced users "just have to change it if they don't like it"? Try replacing systemd on Ubuntu, let me know how it goes. You don't want snaps? Well it looks like it may get harder and harder to not use snaps, because people like you think that it is fine to enforce the most used tools as "the standard". You want to use a tiling window manager? Well many apps will just suck, because people assume that the "standard" is Ubuntu. Same for those apps that require network-manager, or the gnome keychain, etc. The "Linux way", IMO, would be to create CLI tools with minimal dependencies, and then build GUIs on top (maybe even specialized for the latest Ubuntu). But that's not what's happening. You want to use Firefox as a browser, and have a lightweight calculator app next to it? No luck, chances are that your calculator app is shipped with Chromium, because people decided that the standard is Chromium and webapps. And that's if you're lucky, because your calculator may be shipped with a full rootfs in a docker container.

So from my point of view, there are people coming from Windows/macOS to Linux for some reason (apparently not the freedom of Linux, because they don't even wanna know how their system works), and argue against my freedom, because if I don't want the Windows/macOS experience, then I am a weirdo.

> So, yes, there is a set of defaults on Linux.

You mean "the defaults of Ubuntu, which represents most Linux Desktops"? I don't want it. I want the choice to choose the distro closest to my preferences, and let Windows/macOS people choose Ubuntu. But that means that those Ubuntu people should not insist on everyone doing what Ubuntu does.

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 have to use ShiftCmdV if I want the full suite of paste options.

So I guess I feel confused about why you'd rant in defense of "those who like different shortcuts," and then call out macOS specifically, when that's an area where it shines over all others.

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 that in the system-wide settings?

I would guess that macOS does not strictly enforce the system bindings, does it? Say it does -> application developers lose flexibility because they can't design a different UX if they want to. Say it doesn't -> application developers now have to decide, for each binding, if they want to define a default themselves (which would be consistent with the rest of their app) or if they want to honor the system bindings (and possibly have a terrible UX that people will complain about).

It's not an easy problem :-).

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.

But I wonder about key bindings. I think it makes sense to have guidelines, and to use "Cmd + Q" to quit whenever it makes sense. But defining this as a high-level action "quit", and letting the user define the binding (e.g. "I want Cmd + S to quit") seems rather complicated to me. If "Cmd + S" is already set system-wide for the "save" action, then the system could tell you "that will disable the 'save' action, are you sure?". But if you go for "Quit with Cmd + J", and "Cmd + J" is not a system-wide binding but instead is used by... say... Blender. Then the system will happily change "Ctrl + Q" with "Ctrl + J", and now what happens if you hit "Ctrl + J" in Blender? Should it quit, or should it do what Blender does for "Ctrl + J"?

I am not sure everything can be configurable. My Firefox toolbar is at the top, on mobile I can have it at the bottom (not sure I can do that on Desktop). But I can't have it in the middle of the page, or vertically on a side. That's a decision that was made by the Firefox devs, not by the system settings. That does not mean we should not expect sane defaults, but I would argue that ":q" is a sane default in vim.

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.

How is this not trivially solved by having the app ship with its own set of bindings, then provide a simple toggle switch between "use app defaults" and "use OS defaults/user preferences" that is displayed on first use?

> 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

The above system seems to fairly easily fit your preference - you can trivially choose to use the app bindings, and GP can trivially choose to use the system bindings.

You're advocating for needlessly restricting user choice by using a design that doesn't allow them to pick between a unified set of system shortcuts (which I, and many other millions of people want) and each app doing it their own way (which is a UX disaster for new users).

Nope, I'm advocating for letting the app developers do what they want. Enforcing apps to honor the system-wide defaults (not even talking about how to actually enforce it) would just break emacs and vim, for instance.

> How is this not trivially solved [...]

Well first you need to find a way to integrate that toggle in your UI without people complaining too much. Then you need to test that it works on your platform (I see a lot of room for errors, e.g. if the system default is not set, or set to something weird, or conflicting with another app), and then you need to make it work on other platforms (which most certainly won't provide a compatible API). Sounds easy, in practice nobody would want to pay for the work required to do it.

That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.

You're contradicting yourself. Your comments above are specifically arguing against the idea of implementing this system at all:

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

That is an argument against the OS-meddles-with-the-keybindings system, period. Your statement "I'm advocating for letting the app developers do what they want" is flat-out false - you are advocating against app developers implementing this system at all (and therefore advocating against letting them do what they want) by claiming that it is a bad model.

Additionally, you're trying to quietly change the discussion from "what makes things best for the user/what is good UX" (which has been the actual conversational topic) to "what do app developers want to do" which is completely orthogonal and irrelevant to this discussion.

> Well first you need to find a way to integrate that toggle in your UI without people complaining too much...

...and now you've stopped trying make arguments about the concept itself, and are trying to start arguing about hypothetical implementation problems to argue that the concept is unsound. (MacOS has effectively solved all of these problems, by the way, so this line of reasoning doesn't even pan out - MacOS's model is existence proof that such a system can be effectively implemented and that users will like it)

> That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.

Finally, there's more redirection from "is it a good idea" to "will people implement it" - again, unrelated and irrelevant to the conversational thread.

Do you have anything actually relevant that you'd like to add?

> Not having system wide keyboard shortcuts is one of [those big mistakes]: vim, emacs, nano etc all have a different shortcut to quit the app

In my opinion (and that's an opinion, not a formal proof), this does not work. _I do not want the same shortcut to quit nano, vim and emacs_. The author of that comment does, obviously. Which is why I said "preferably the standard should be your favourite shortcuts, right?". Not as a criticism, but in order to show that this is a preference, and my preference differs from the author's.

My preference is to have vim bindings be vim bindings, and not the system bindings. Sure, the system settings could offer a way to specifically set the bindings for vim instead of using the `.vimrc`. But it would not entirely replace `vimrc`, so it would split the config in what _I see_ as a weird way.

I generally don't see how it would work in practice. I can easily swap "ESC" and "CapsLock" in the system settings, but that's not the same level as setting the shortcut for a high-level action like "save". If you want to set the "save" shortcut globally, then everyone writing a program has to deal with it. First, I don't see how you can enforce it. And second, it makes life harder for developers. For something _I don't personally want_. Therefore as a developer, I won't follow your preference, period.

This is my opinion about the hypothetical idea of having system-wide settings that would unify vim, emacs and nano (that's the point of the sentence above, isn't it?). Maybe someone can implement this in a perfect way, and I would even use it (who doesn't like "perfect"?). But it _feels_ like I fundamentally disagree: _to me_, the fact that vim, emacs and nano all have a different way to quit the app is a feature, not a bug. Therefore it does not need fixing.

But feel free to explain to me what I am trying to say, and why it is logically wrong.

Your past shortcut change is something I’ve done similarly but you can also assign shortcuts to menu commands that you use often but don’t have one, etc.

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.

Also calling personal preferences of lots of people “stupid” is far from reasonable. I’ve met a lot of smart folks who used vim and emacs, so from my personal experience it’s not correct.

But right now, I would say simply: "if you want the macOS philosophy, use macOS". And don't get me wrong: macOS is great.

Not even Microsoft has system wide keyboard shortcuts. And copy paste on Microsoft has become a game of luck.

Huh? I've used all versions of Windows from 98 onwards, and things like Ctrl-Y/X/C/V/Z, Alt-F4, Alt-Tab, Ctrl-Alt-Del, etc have all worked extremely reliably.

The one exception is the keyboard shortcut for 'redo', which some applications like to bind to Ctrl-Y, and some others like to bind to Shift-Ctrl-Z.

Sure, later versions of Windows have added additional shortcuts like Win-Tab, Win-V (for clipboard history), Shift-Win-S (quick screenshot), Win-X (superuser menu, since Windows 8), but these are absolutely welcome additions.

It's different for programs running in terminals / terminal emulators for technical reasons. Terminals are not GUIs, they are simple devices with a single byte stream for input (displayed on screen) and output (sent from keyboard) that are interpreted quite literally. E.g. the byte ASCII 'A' will normally result in an 'A' being displayed whereever the terminal cursor happens to be. Typing 'A' on the keyboard will result in 'A' being sent out to the OS. Ctrl+(A-Z) will send the byte values 1 through 26. E.g. Ctrl+C will result in ASCII 3 (0b00000011), aka ETX (End of Text), which will normally be converted by the OS's terminal subsystem into a SIGINT signal that is sent to the "foreground" process running in the terminal. Or, if the terminal is in raw mode, the byte 3 will be read as-is by whoever reads the terminal keyboard. Same goes for ctrl+z (normally SIGSTOP is sent) etc.

Terminal apps can't expect a running clipboard service. There may not be a display or graphics environment running on that machine. The app might run on remote machine. Etc.

Notice how Windows Cmd isn't entirely intuitive about those basic cut&past things, either.

ctrl + a (abrir, open in Portuguese) instead of select all, that is moved to ctrl + t (tudo, all in Portuguese), and many others.

So, universally for English/US I guess.

* nano? Real Programmers use emacs.

* Hey. Real Programmers use vim.

* Well, Real Programmers use ed.

* No, Real Programmers use cat.

* Real Programmers use a magnetized needle and a steady hand.

* Excuse me, but Real Programmers use butterflies. They open their hands and let the delicate wings flap once. The disturbances ripple outward, changing the flow of the eddy currents in the upper atmosphere. These cause momentary pockets of higher-pressure air to form, Which act as lenses that deflect incoming cosmic rays, focusing them to strike the drive platter and flip the desired bit.

* Nice. 'Course there's an emacs command to do that.

* Oh yeah! Good ol' `C-x M-c M-butterfly`...

* Dammit, emacs!

https://xkcd.com/378/

  $ cat <<EOF > test
  > this is a test text file
  > written with cat
  > EOF
  $ cat <<EOF >> test
  > this is an extra line at the end
  > EOF
  $ cat test
  this is a test text file
  written with cat
  this is an extra line at the end

It’s only a problem if you make mistakes. Real programmers don’t, hence cat is perfectly cromulent.

>But not sure how you modify them.

Maybe somehow sending escaped "backspace" symbol?

   cat > myfile.txt

Dropping people like that into an editor that requires you to somehow know ":q!" is the answer is utterly insane. Same with beginner tutorials using vi.

It's straight up bad for linux adoption even if technically superior. Anyone that is a vi fan likely has the skillset to install it themselves - the reverse is not always true.

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. All we have are artificial comparisons where it takes Vim 37 keystrokes to transform a Christmas carol into the lyrics of a death metal song, while it takes Nano an unacceptable 51 keystrokes to do the same (of course, this only works if you take half an hour beforehand to mentally construct that 37-keystroke sequence).

The pros of modal editing is well documented, and I'm not even arguing about the superiority of vim over the likes of emacs.

People who believe using cursor to select, move, copy stuff are better than modal editing, even after all the argument, is probably not going to be swayed ever. As an almost pure vim user, I know how my own speed are significantly improved ever since I adopted vim and its modals, and I don't need to mentally construct keystrokes just like most people don't need to look at a keyboard to type.

The demonstration are mostly some edge cases that don't really happen, but the general speed over general editing, some `V}y` here, some `ci(` there, some `Vjj2>`, `c-vwwGx` etc is what makes vim really shine. And no we don't have to dig a dictionary to type those things, all I had to do was to open vim since that's how muscle memory works.

Finally! Someone who knows where that elusive data is hidden that actually shows why modal editing is better.

Wait, did you forget to link to the study?

On previous tens of discussion surely someone has came up with something, only for you to dismiss it as gimmicky. I am not going to spend much effort on a lost cause, but quick googling came up with this blog: https://eli-rodriguez.com/en/posts/modal-editing-the-superio...

Enjoy moving your cursor around when you edit text, but welcome to the club if I am wrong and you can be convinced.

Impressive.

This is made especially difficult by the subjective nature of discussion.

Let's take a step back from vim: what kind of data will demonstrate satisfactory performance over any kind of editor for your liking?

I mean, there are studies examining how the quality of Git commits is affected by blood alcohol levels, so that doesn't seem like an overly exotic topic by comparison.

This seems like a classic case of setting the bar arbitrarily high to stifle discussion - I cannot find any, but would love to be proven wrong.

I don't know, you tell me. You're making the claim that one is superior. The burden of proof is on you.

Asking specifically to a level of proof that does not exist either way on a subject that does not pertains to such a level of proof is merely stifling discussion, not to mention that the claim that the editors are equal in capability are not immediately obvious and proof absolving.

Though it's convenient for you that you consider anything higher than your own standards "infinite".

  yypVr-

I wonder if you've ever seen scientific evidence of the contrary? Or any kind of scientific evidence on this matter?

If not, it seems that you're just using this as an excuse to rationalize your own prejudice, and the counter-argument is really easy: absence of evidence is not evidence of absence (in this case, or vim's advantages)

Even if you don't believe that there's a speed advantage (it's entirely plausible that the delay from cognitive processing necessary to navigate vim's more complex interface dwarfs the speed increase of pressing fewer keys), I find it hard to defend the idea that pressing significantly more keys is not ergonomically worse than pressing fewer (controlling for effort variables e.g. using the Carpalx model[0]).

[0] http://mkweb.bcgsc.ca/carpalx/?typing_effort

I can’t really compare to eg. Emacs bindings, as I have no experience with those, but most text editors have nothing, and if you have to reach for a mouse or arrow keys instead Vim is imo going to be much better once you’ve learnt it.

But the whole modality thing is insane for a newbie; vim is a fine editor as a conscious choice of course.

That cute bottom bar is the reason Nano wins. It provides a safety net.

https://micro-editor.github.io/

https://helix-editor.com

https://github.com/helix-editor/helix

Does anyone else use this? (To be fair I am transitioning to vim now that my emacs muscle memory is waning, and the rate of jed bugfixes likewise).

When I got into Linux there was no nano, only vi and ed. Pico came later with the Pine e-mail client.

Nope. GNU Nano, like a lot of the early GNU utilities, emulates Pico. I was using Pico/Pine around 1994/95 on UNIX workstations, and Pico was the default editor.

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.

Nano is interesting in that context, because for many it's the "default" editor, which is a bit weird if you came in to Linux/Unix earlier. I bet a lot of people feel the same when it comes to anything besides ed, though ;)

Still, it led me to a deeper read of the configuration and I ended up enjoying nano more after that. It's come a long way in recent years too.

However, as a default for new distributions, nano is a solid choice (with the command help on the bottom). Any experienced users can just type vi, or update the EDITOR env var. It's about as friction-less as running a different command.

However, once you grok vi, there's no going back.

Cracked me up good.

If you don’t like that kind of editor, that’s fine. You do you.

That's given me a lot less patience for people wishing to re-train me for some alternate way do do the very basic things in life. Standard interface design is a great idea. The standards we use, even QWERTY, are a lot better than many would give them credit for.

So is nano saying

- SHIFT-[6](^)-SHIFT-X

- SHIFT-[6](^)-x

- CTRL-[6](^)-SHIFT-X

- CTRL-[6](^)-x

All I see is '^X', on my keyboard '^' is on 6. Why the hell isn't this working?

Little does little Sally know that this is a UNIXism, carat means 'CTRL', X is really just 'x' - but how would Sally know? Sally was just trying to do a simple git commit to get used to using Linux in the first place. Is it little Sally's fault for not knowing? No! Will little Sally have a bad taste in her mouth due to using an unfamiliar tool? Yes. And there you go, little Sally has went on back to Windows. -1 user.

Fair. Have to say though if you just invoke `nano` (that is nano isn't opened with a file) there's a tooltip saying check 'Ctrl-G' which explains that ^ is Ctrl and M- is Alt.

There is no reason to assume the worst. It only detracts from the discussion.

Remote VSCode is kind of magic, I'm increasingly working in (local) VMs via it. I have one project that is probably never going to never going to support ARM, and I'm close to needing to upgrade my MacBook. I really want an M2, but this project would be hard to run locally on it. VSCode on a remove VM is probably going to be the answer.

I installed about 10 plugins that made my vim look almost exactly like Atom, except much faster, I also had a script that could install the exact plugins in any unix system in a few seconds, very useful since I work with VMs.

Best of both worlds, people often forgets/don't know that vim are actually more configurable than other editors - colors, layouts, you name it.

To connect it's just plain ssh, so as long as you can login you can use it remotely. As soon as you connect it gives you a file file browser to select the root for VSCodes built in file browser side bar.

My understanding is VSCode has a client/server architecture and so this was considered in its architectural design from the beginning. Along with file io, it's runs the language servers, git, terminal, and many other plugins remotely.

Not all your plugins will initially be installed on the remote, but it's just a case of going to the plugins panel and clicking one button to install and enable on the remote.

An alternative approach might be to mount the remote directory as a file system with sshfs.

I love mcedit feature that lets you pipe selected text through a custom bash script.

Turbo Pascal was the ultimate in text editing. In fact, it was a complete IDE in a TUI. And the most-used commands were single keystrokes. Edit-run cycles were so fast that I was writing programs to do regular automation tasks.

I do all my coding in nano, and I'm more than happy. I gave vim a sporting chance, know how to use it reasonably well, and do use it comfortably when editing collaboratively with a vim user. But nano just works, and without having to go through silly mental hoops. And for all the "mental efficiency" talk, in practice 99% of vim users I have interacted with either end up ignoring all the complicated stuff such that vim actively ends up wasting more of their time to do otherwise simple stuff, or manage to shoot themselves on the foot for every other "clever" thing they try to do.

The latest release (7 onwards) has also become even more powerful, now that it allows function calling in macros (previously you could only use pre-bound keybindings)

What drives people to make comments like this? Why not either put in the work to understand the point, or just move along?