Toward a “modern” Emacs

There are quite a few, mostly for markdown, and mostly limited to literate programming. See rundoc, codedown, gfm-code-blocks.

Really? I've always found emacs to be on the slower side of things (not nearly as bad as jetbrains / visual studio, of course) and many keyboard commands to be unnecessarily clunky. I don't know how many times I've given emacs a go, and yet I can't seem to get nearly as proficient as I am with VSCode (and sublimetext before that).

I know part of it is that I don't typically work in languages where having a live REPL up is terribly useful, so emacs support tends to be a bit... second class.

I think my biggest gripe is that there are actually two mountains to climb. First, you have to become proficient with emacs- the chords and so forth. Then you have to find the magical combination of plugins that work together on your operating system with the magical configuration that brings emacs up to par with things that I consider to be table stakes for a good development experience. Doom emacs probably got me the closest there, I think, but struggling to become moderately productive when I already have a tool with which I am extremely productive seems entirely pointless.

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