For a lot of tools, both in software and other fields, there are three different classes of user.

1. Those with fairly straightforward tasks that they just want to get done.

2. Those who mostly have staightforward tasks, but occasionally have something a bit more complex but not too complex.

3. Those that need to handle everything from simple to ridiculously complicated.

Take electrical testing tools for example. For a lot of people a simple battery tester is all they need (class #1). If you want to test a battery and have never used a battery tester before, it will either be obvious what to do, or a glance at the instructions will tell you.

Some people need a bit more on occasion, and for them we have a class #2 tool, the multimeter [1]. You can still pretty easily test a battery with one, but the first time you probably will have to spend a minute or two in the manual, learning what voltage setting you want (the V with the ~ over it, or the V with the dashed and non-dashed line over it?) and which holes to plug the probes into.

Some people need a lot more. They have a class #3 tool, the oscilloscope [2]. You can check a battery with an oscilloscope, but if it is your first time you are going to spend a lot of time in the manual before you get there.

Emacs and Vim are class #3 tools.

[1] https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87...

[2] https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-O...

You don't need Emacs or Vim to be an incredibly successful software engineer. It's actually the opposite, Emacs and Vim users are a minority among successful software engineers.

So they are only a specific kind of power tool.

More than that, they can't even handle the "ridiculously complicated". Common examples are trying to use them with projects containing millions of lines of Java or C# code.

But using a more advanced editor can make it easier. If you are going to be doing software engineering for a few decades all the times you have to do some repetitive task in a simple editor that would have been quicker in a more powerful editor adds up.

I'm arguing that IntelliJ/Visual Studio are more powerful than Emacs or Vim.

The Emacs and Vim architectures are antiquated and the volume of effort put into developing them (and their ecosystems) are outclassed by modern IDEs, especially for languages that scale to large numbers of developers working together (Java, C#). Emacs and Vim are poor man's IDEs compared to actual IDEs for these cases.

Emacs and Vim are mostly popular amongst C/C++ developers, where the ecosystems are generally baroque, forced by the need to integrate with embedded systems with limited toolchains or with libraries/frameworks that are very limited, and amongst developers working with dynamic languages, where you generally have small teams. Or large teams and a ton of headaches :-)

However, that in itself is not my reason for preferring Emacs. It's also my markdown editor, often my file manager, my PDF viewer, my image viewer, my git interface, IRC client, email client... I could go on, but I'll stop there.

Emacs is not and has never been an IDE, it's a highly versatile and extensible text-editor. You can't compare apples and oranges.

Outclassed in what way?

Have you looked at LSP[1] and its support in Emacs[2], for instance?

That's not to mention things like SLIME and paredit for Lispy languages, or the integration of the rest of the Emacs ecosystem in to your development environment, the ability to develop and configure all these development tools in Lisp instead of being forced to switch to some other language, etc.

[1] - https://github.com/Microsoft/language-server-protocol/

[2] - https://github.com/emacs-lsp/lsp-mode/

This is not surprising; it's no different from Vim users who have never written or debugged a line of VimScript.

[1] https://xkcd.com/1205/

Donald Knuth. Author of "the art of computer programming" and many contributions in computer science.

Linus Torvalds. Original author of Linux (the most widely used kernel) & git (most widely distributed version control). In fact, he wrote his own version of emacs. He doesn't do much, if at all, coding now.

Joe Armstrong. Author of Erlang.

Guido van Rossum. Author of Python.

Yukihiro Matsumoto. Author of Ruby.

Rich Hickey. Author of Clojure.

Andrei Alexandrescu. Author of D.

Xavier Leroy. Author of OCaml.

Michael Widenius. Author of MySQL & MariaDB.

Guy Steele. Co-author of Scheme.

Stephen Wolfram. Physicist, computer scientist & author of Mathematica.

Peter Norvig. Research director at Google & well known Lisper.

RMS. Well, original author of GCC, Emacs & the GNU system.

All of them, apparently, don't require one of those "powerful" IDEs.

VSCode would need to be 10x better for the seasoned veterans to justify switching. If it were only 2x better, arguably the investment would not be worth it, but it doesn't change the fact that VSCode would be 2x better than emacs.

At the end of the day, it's kind of just shifting around based on what feels good. It feels similar to sitting in a cafe for a bit, but some times working from home, and some times in the mountains.

But there's no need to put people down by saying stuff like "poor man's" IMO. And if you're restricted to what makes C# and Java tolerable, that's a small space. There's a lot more stuff out there.

And programming is not as simple as "make decisions that optimize your engineering throughput" IMO. Otherwise gardening would be agriculture, right? Both are important in their own ways.

In any case Vim's terminal emulation and asyncness these days along with coc.nvim brings it back on track IMO. There was a period where it was behind.

I do think it depends a ton on language. The best experience in Vim is editing Go, I think. And then TS and C++ have been a close second. Lisps are not great, Emacs tends to better. For Java and C# it's definitely IDEs. VSCode is also fine for a lot of langs, in a more out of the box way. Cursive is also good I hear for Clojures. If you need to move between a lot of langs, the only IDEs that pan out are IntelliJ mostly, unless you count Code as one. But Vim and Emacs have the best multiwindow and multi buffer management. And the best git integration for patch by patch staging, for sure.

And ofc for ObjC and Swift it tends to be Xcode. If you're really into Freepascal then Lazarus etc. Smalltalks are their own thing ... it keeps going on.

The name "Microsoft Visual Studio" refers to a product line with a long life, which had been a monumental piece of shit over most of that life.

Vim and Emacs helped people survive Windows development jobs centered around Visual Studio.

Also I hit Cx-c by mistake thrice a week.

  ;;; Make it more difficult to kill emacs accidentally
  (defun my-kill-emacs ()
    "Confirm before 'save-buffers-kill-emacs'."
    (interactive)
    (if (y-or-n-p "Really kill Emacs? ")
        (save-buffers-kill-emacs)
      (message "Aborted")
      )
    )
  (global-set-key "\C-x\C-c" 'my-kill-emacs)

My emacs uptimes (M-x emacs-uptime) are generally the same as my machine's uptime, which is typically months. Emacs is one of the most rock-solid pieces of software I have running.

It's also great for remote. I have emacs daemons running continuously on my remote boxes. To start work on those machines, I log in and start my emacs client. I've never had a need for things like "screen".

My understanding is that without screen/tmux, the process will die if you disconnect the shell (on a remote box).

Interesting that --daemon works too (I've been running emacs through tmux for years, and never knew that).

Unbind it. Problem solved. That's what I do with my clumsy fingers.

A slightly nicer embedded docs. They were great for 80s way of life, but it could use a slightly more reply (to stay in the context of a live editor / lisp machine). Maybe a text demo system.. after all you could script a demo of workflows in elisp for newcomers to see rapidly.

- hydras could be extremely useful for newcomers for instance (and I'm no fan, but it cuts the chase by a factor of 1000)

- ace-jump

I don't know, I'm just suggesting

They're a big part of what make Emacs useable for me.

I have set up hydras for pretty much every major mode I use (except magit, which kind of has its own hydra-like menu system).

Because of hydras, I don't have to remember all the arcane keyboard shortcuts these modes have bound by default, and don't have to look up how to run a function that's not bound at all.

All I have to remember is one keyboard shortcut which I have configured to bring up a hydra in every mode, and it'll show me a menu of everything I can do in that mode.

This is really fantastic, has revolutionized the way I use Emacs, and has made it 10 times as useable for me as it was before I used hydra.

I wish 'UI autocomplete' like this was a standard feature of operating systems. GUI's aside, how nice would it be to run a CLI command with some flag that allows you to explore the various options and string them together, rather than reading the manpage and searching for whatever flag you might want to use?

It is also a piece of software where changing the terminology is very difficult. While a non-scriptable program could simply change the documentation and be done with it, Emacs would either have to change the names of exposed functions (breaking compatibility) or have one set of terminology for scripting and another while discussing the user interface.

Perhaps better choices could have been made, but the issue is non-trivial.

I've put in a ton of time and effort configuring Emacs (after spending about 25 years on vim and vi), and though it took a long time, the results have been well worth it for me.

There's no way I would give that up and go to something with more reasonable defaults but which is much more limited in customization capabilities and which lacks a Lisp ecosystem which has been improved by thousands of people for many decades.

You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults.

You'd still be able to customize it (after all, you probably did) and all the newbies wouldn't have to read about 80's computing arcana to figure out how to split a window.

That's the rub though. Emacs could change its defaults, plan large deprecation and rename, rewrite all its documentation and write even more to help migrate. And 20 years from now someone will be whining about the 2010 "web arcana" embedded in some interface and command set.

> newbies wouldn't have to read about 80's computing arcana

Because here's the perfect example. Emacs isn't 80s computing arcana, it's 60s computing arcana largely encoded into it in the 70s. In the early 90s when I first picked it up there was a similar push to encode the arcana from the 80s instead. "Pick the standard keybinds that make sense!" they said. Like Shift-Delete for cut and Shift-Insert for paste!

... oh, that's probably not what you want today either, is it?

So here's your options:

- Churn the defaults and everyone's configs every 15ish years

- Document as best you can the defaults and how to change them, and make the best UIs you can at the time, in fashion or not. (Kill rings are still better than cut buffers!)

Universal "reasonable defaults" don't exist in a tool meant to last 50 years in an ecosystem of fads.

At a certain critical mass, soft-ware stops being soft. Other things bend to accommodate the soft-ware.

You know what's even harder than hard soft-ware? Social mores and expectations. For example, such as those formed by millions upon millions of spreadsheet users.

Or billions and billions of web users.

So, where am I going with this? Emacs has encoded some norms from the 60s when the tech community was probably 0.1% of what it is now, and when large numbers of those 0.1% people were technically adept and very flexible in adopting new things.

"Web arcana" has been assimilated by a million more applications and systems than those systems that inspired Emacs had. It has also been assimilated by billions (!) of people.

60s arcana is not equivalent to web arcana, for this reason.

When we hadn't even standardized the keyboard layout and the "display" was a dot matrix printer? When there was no networking to speak of?

How does that make more sense?

I can throw the bullshit rhetoric right back at you: You think absolutely nothing was better in the 60s? That modern IDEs lost nothing compared to the tools of 10, 20, 30, 40, 50 years ago? Why isn't Emacs like Borland? Why isn't Emacs like Visual Studio? Why isn't Emacs like Eclipse? Why isn't it like Mosaic, QuickBasic, Coldfusion? There are reasonable answers to these questions, and they'll tell you also why Emacs isn't like whatever you want to compare it to today.

Maybe Emacs already occupies a local maximum, "a middle ground", taking some of the best compatible ideas from the times it's been alive in. Vi another local maximum. IntelliJ or VSCode, others - but emphasis then on local, and I hope you like retraining.

The problem is not keybindings or what decade its metaphors exist in, it's people see Magit or Org or whatever high-level fully-integrated tool, and want just that. And you don't understand that is an outcome of a path that really does require the whole philosophy to ingest into your workflow. But you don't want to learn the philosophy, you just want to 10x crush git or whatever. No, it won't happen. There's all sorts of dumbass metaphors in in this thread now, but in the end Emacs is garden, not a hammer or a workbench or an oscilloscope or whatever. You get out proportion to what you put in, you work with it not just use it.

Shit's just gonna get faster. You need to find ways to live with it, not copy it. Talk to your fathers-in-law.

You could bundle up maybe a dozen keybinds like this, but it's not going to scale to even address the complaints we see in this thread (window vs. frame terminology), let alone the full gamut of mainstream Emacs configuration. And it's a massive amount of work to do. And it's not fundamentally different than just picking an Emacs-distribution-du-jour (Spacemacs, Doom Emacs) right now.

If that's what you want, my view is you might as well be churning whole editors. And truthfully, if that's what you want, do it! But I want a kill ring, and buffer/window management that doesn't presuppose multiple frames, and my mode line. I don't want to waste critical keybindings like C-x or C-c on weaksauce single-buffered text operations. And yeah, there's a lot of things I would change if I was doing "Emacs from scratch", but on the other hand I don't need to because I can change them now, and easily share them, and still take advantage of what everyone else is doing.

I've never tried any of them myself, because I already have Emacs configured to my liking, but reasonable defaults is what these packages aim at.

You could try Spacemacs. I've only just started seriously getting into Emacs, and have found Spacemacs to be a big help.

C-x 4 is a prefix for "other window".

C-x 5 is a prefix for "other frame"

(It's OK if you did not know this. I was a heavy Emacs user for a decade before I learned this).

For your particular problem, you may want to look into Hydra. Setting up your own Hydra for dired-mode will involve some basic Elisp, but not much - you can just copy/paste from elsewhere. However, you may need to write an Elisp function for your particular situation, and then have the Hydra call that function.

Similar to another commenter, once I learned hydra, I create my own menus for every new mode I want to use. Much easier than memorizing keybindings, and you can put your own custom stuff there.

Also, I rebound F6 to switching windows. C-x o would drive me nuts. F6 is the standard in Windows/DOS, so that's what I was used to (I still use it in Outlook for work to avoid the mouse).

The straight documentation on the parts? I'm curious how you would want those to be otherwise. They mostly read like the user's manual of a car. Fairly technical, but at a very high level. With occasional tips on how to use the part you are reading about.

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.

Also some of the plugins augment Emacs so much that some people see them as part of emacs rather than an add-on. I don't use dired; I use helm/ivy.

I am having good luck with Doom Emacs. You may want to check it out, especially if you are used to the Vim keybindings. It provides a lot of extra functionality out of the box.

I'm on the other end of the spectrum, I'm betting that computers will become fast enough with time to run these bloated editors that were designed to be usable.

You must be referring to `C-x b` vs. `C-x C-b`. I remember getting apoplectic over this in 1995. I remain aggrieved to this day.

My recommendation would be to bind `C-x C-k` to `kill-this-buffer` and unbind `C-x k`, or bind `C-x C-o` to a hydra that lets you repeat `C-o` i.e. hold down ctrl and repeat `o`, to cycle windows. Or both.

Alternate, try out `ace-window`.

I'm not sure about "too easy to confuse for a newbie." These kind of mistakes only happen when you are switching buffers rapidly without checking prompts, and newbies won't be doing that. And the default mnemonics are (unlike much of Emacs) good for these tasks. So rebinding doesn't feel like a big ask.

(Agreed `C-x b` should be removed imo.)