> Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything.

But that's the point: it doesn't.

Maybe it does if you want to invest a few hours getting up and running, but I don't have that kind of time: I need to get stuff done now.

I'm not saying I'm too important, or my time is too valuable, or any nonsense like that: I just don't have time to invest in spending a day or even half a day learning what are in contemporary times the basics of using a text editor.

And that's the problem with the tutorial: it doesn't start with a quick two page summary of what, in contemporary times, are considered the basics of using a text editor. It's long-winded and academic and takes way too long to get to the point on any and all relevant topics.

The result is that I have to (and not just me: anybody used to non-emacs - or perhaps vim - editors) invest non-insignificant amounts of time learning basic functionality that works in a common way across most other editors and IDEs (IDEA, Visual Studio, Rider, VS Code, Sublime, TextPad, XCode - heck, even Microsoft Word) and learn completely different paradigms for all of it just because emacs is "special". It's pretty frustrating because for me the editor is not the point. I'm only looking at emacs at all because a lot of editors, once you get to a project of any size, become absolute CPU hogs and it starts to get in the way. But given the grief I may come to the conclusion that a better investment is just to buy a faster laptop.

I'm totally happy to be proven, or to prove myself, wrong, but right now the whole emacs ecosystem seems unnecessarily, contrarily alien simply for the sake of it.

There also seems to be a strong lack of empathy for users. Few influential people seem to have given any consideration as to how to make the software accessible for newcomers. In this day and age that's almost laughable.

I'm not sure I follow. As a power user of computers for years, I would be a liar if I said any of those programs were "quick to get running." Speaking as someone that is getting my kids up and running with computers. Training and tutorial running are the norm and should be. Expecting proficiency in anything with less than a few hours is an exercise in pain.

If you want there to be a new tutorial, I don't know anyone that would be against it. The "game to learn vim" was popular a few times. Same basic idea. I don't know what I would make of it, right off. There are some great typing modes that let you quickly type the current document and score you on speed/accuracy. Moving to other windows is tough in any option. But I could imagine a fun game made to navigate through. (Though, with helm, most navigations are autocompletes nowadays.)

I hate that it feels like a lack of empathy for you. But I really don't see the ecosystem as alien. Any more than I see the python ecosystem as alien, or the java, or javascript, browsers, etc. They are all just a little different. But all have some rough analogs. And all feel like they are just trying to shield users from complicated problems. Many times making things more complicated in the process.

What I'm trying to say is this: I can pick up almost any text editor and be productive immediately, even if I've never used that editor before. That is manifestly not true with emacs (or vim). Getting back to my point about the emacs documentation, it is simply not optimised to get me productive in the way I can be with other editors anything like as quickly as I can become productive with those editors.

Of course you're right, when you start using computers everything is hard, but many applications have common conventions, even across different authoring organisations and people, and even across different operating systems.

Emacs has conventions but there's next to no commonality with other applications within the same broad class, so you are starting from scratch. Emacs makes no affordances for people who are already used to using other software, whereas much other software does make those affordances, and so is easier to pick up as a result.

Maybe you don't see that as a problem, and that's fine, but for me - and, I suspect, quite a lot of other people - the steep learning curve feels unnecessary and, frankly, bizarre to the point of being out of place.

There's no reason Emacs couldn't be easier to use. There's no reason the documentation couldn't be written to accelerate proficiency with the application. But neither of these things is the case, and it's a deliberate choice. As I've already implied, it seems almost obtuse just for the sake of it.

> I can pick up almost any text editor and be productive immediately, even if I've never used that editor before.

It's true, but I don't see why this is being given much importance. If you pick up any editor and use it only to the extent that you can without ever having to read up documentation, then simply go ahead - you likely do not need power features. If you need to do powerful things, then I suspect you will need to read docs regardless of the editor.

Emacs is a powerful tool. If you only need basic editing, then don't use it. That you can't do basic editing with Emacs without even going through a tutorial is not a flaw of Emacs, and you are clearly not the target audience for the program.

And my point is that you have plenty of other training in those editors you are ignoring. Not out of malice, but because it is second nature. You have done a ton of training on them already.

I know it will sound contrived, but when I sit at a coworker's desk using sublime, I'm literally lost on how to navigate. I don't even know how to get the editor to list all open buffers. IDEA? I mean, I know it has the functions, but it is a search every time I have to try them. (Again at someone else's computer.)

I could think it was just my emacs knowledge not working, but I see the same hiccups from folks moving from each. So it isn't just me.

Are there affordances that are common? Yeah, but many have changed, and not all over long timeframes. Worse, many are different from Windows to Mac to Linux. There is a good argument for adopting what is native to where you are, but the rise of browsers has shown that to not be that important, ironically.

I do see it as a problem, if it is keeping folks from using computers. Or, if it makes folks build things that can't be used from emacs. That said, I don't see it as an insult or as a problem if you choose to use something else.

Again, for many of us, emacs is easy to use. For many of us, the documentation is written in a way to accelerate proficiency. I would love more documentation or affordances to help. So not stonewalling, but I caution against the attitude that what is there is bad.

And I get it, I think. I have recently tried to plunge into Blender and Gimp. Holy crap do I feel punished for mistakes there all too easily. :(

> Your complaint on the documentation reads oddly. You do know there is a tutorial included, right?

The tutorial covers only the very basics. It's less than 1% of the material in the manual. And I definitely agree with him - most Emacs manuals (whether for Emacs or for some packages) are written more as reference manuals than something to learn from. If you're lucky some of them will have a tutorial in the beginning.

But this was my point. Most of the documentation is a reference manual. Is why I referenced the user's manual for a car. You will not be using that to learn how to drive a car. Nor will you use it to learn how to build or maintain one, really.

So, to that end, what makes the manual of VSCode/Atom/Sublime good? Since there is an implicit comparison to those as a good comparison.

VSCode/Atom/Sublime all operate broadly the same way. To continue the car analogy, there's a wheel right in front of you, two or three pedals by your feet and a gear stick next to you.

In this analogy, emacs' accelerator is on the ceiling, the bake hangs off the side and to steer you need to tap out the morse code for the words left and right on the dashboard.

Can you become proficient using that kind of interface? Probably.

Can you change the interface to something more sane? Sure, but you have to first learn how to weld...

I think that is being deliberately unkind to emacs. It would be closer to comparing it to a car designed 30 years ago in a country that drove on the other side of the road. Most all of the major points are the same, just in a different location.

Even better, compare it to driving a boat, when you've been used to cars. (Or, for that matter, realize that it is a stick shift car when you've been used to automatic. And slowly realize everyone has a slightly different way to get their system running as an automatic.)

Given that I love Emacs, I hate to disagree with you, but I must:

This is like a car model that came into existence 40 years ago, but is still making cars today.

Ford is over a 100 years old. Yet I have no problem getting into a rented Ford and driving without consulting the manual.

As someone that used to drive a lot of rentals, I think you overstate how seamless it is to get going in a car. More, I think this glosses over how difficult cars used to be, to operate. With how unreliable early spark plugs and carburetors were, it is hard to state how far things really have come.

And my point is I agree that vanilla Emacs can feel spartan. Thing is, my customizations have aged really well. My config for Emacs hasn't changed too much in over a decade. That kind of stability is hard to put value on. Especially when our industry seems to price itself on instability.