> I've never seen anyone who did the 2 minutes or two hours of work, went into a configuration, and changed these keys. I believe it's true: I don't think anyb

> I've never seen anyone who did the 2 minutes or two hours of work, went into a configuration, and changed these keys. I believe it's true: I don't think anybody could even dare trying to change the key combinations if all the help pages can help you only with the description "META v" means "scrolling down in x jumps" or whatever. In that case one spends time figuring out that these weird pages write each time "META" instead of writing... I don't know what... and then one just "translates" in head each time, cursing the "help" for not being direct. But changing the combinations to make even such "help" even more unusable? No way. The complete mindset would have to be different across all tutorial and references to avoid "hardcoding" the key combinations even there -- the "proper" help would reflect the environment as chosen. The beginner's expectation is that all trivial interactions could be done the way he's already used to perform them, and the "power" of the editor is not in pressing combination a or combination b, but in the functionality which is not present in other editors. For the context: One of my oldest muscle memories are key combinations of Wordstar, a character-based text processor. The the editors on DOS and later Window which targeted programmers had for years default key combinations which imitated Wordstar, or allowed to select them once for all. But most people from that times unlearned these combinations once they started using Windows GUI, expecting that all GUI interactions use the GUI common key combinations, like holding shift and moving cursor using the arrow keys to mark the selection. Some convention came from the traditional Mac OS, initially Windows started with some other combinations than Ctrl-C, Ctrl-V, but I've never used these older Windows-unique (Shift-Insert or something). Of course on Linux GUIs it can still be a mess: https://askubuntu.com/questions/26655/how-do-you-know-when-to-use-shiftinsert-vs-ctrl-v-vs-right-click-paste-to-paste https://askubuntu.com/questions/26655/how-do-you-know-when-t... where sometimes one work and another not when clipboards aren't "shared" with installing some additional program that does that. So let's not go there. Considering the more "stable" GUI platforms (which sometimes also, unfortunately, aren't: some special "clipboard managers" are introduced there too in different occasions) the editors should "fit" to them as much as possible. Is there is any tutorial "start using Emacs based on what you already know when using Notepad, without having to unlearn the basic operations with the keyboard"? At the end a "normal" user just wants to do his job. If some tool allow doing what other tools don't, that's the reason for the tool. Editors, once they become "the environment" for work are however also not normal tools. If the whole production in some company is based on some set of tools, one will accept them "just to get the job done" since anything else would mean even more unnecessary effort. That's how some people learn vi, for example, reading the HN posts. They join a team where it's "how the job is done".