But I believe people trying emacs are attracted by it because something in them makes them crave customization above out-of-the-box productivity.

My theory is that the awful defaults are a test: a baptism of (pretty ugly) fire. It's designed to make you take one look and walk away in amused bewilderment... which I'd say is the right choice for most people! People want "it just works tm". Emacs is not that kind of application.

If you actually go through the crazy slog of making it usable and beautiful, then you pass the test and are hooked forever.

I’m not sure this is true. The enormity of the amount of things that need to be configured before it becomes usable leads new people to use things like Spacemacs etc. This means they rely on other peoples’ config, and aren’t able to customise the editor for themselves.

The same issue exists in Vim. So many nice features of Vim (such as file management using buffers) are underused, because by default they aren’t configured in a usable way.

Otoh Vim has some good stuff out of the box that emacs sorely needs. Completion? ^N/^P and the same prefixed with ^X are very useful, no configuration required, and I have not found anything like that for emacs. Ctags works out of the box. It's a bit weird that cscope integration is worse (you need a script that scans up your directory hierarchy to find the database; ctags support has this built in). In emacs you can install the xcscope package but it's miserable compared to vim's built-in cscope support, and doesn't integrate with evil's tag stack.. sigh.

> Completion? ^N/^P and the same prefixed with ^X are very useful, no configuration required

For each their own I suppose. I despise those bindings and use the tab key instead, like nearly every other program that has completion.

I remember using emacs for C programming with make. M-x compile worked out of the box. I don't think emacs culture would suffer if TypeScript worked out of the box today.

Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands in emacs 9 times out of 10. Emacs still does some fundamentals better (undo), can be used in a terminal and, if you avoid bloatware like spacemacs, also offers better performance. If one is willing to ignore the spyware and proprietary component aspects, vs code by now is a better choice even for most power users, IMO.

> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things

I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development.

For me though it's still not even close.

I find this hard to believe. Not that you may like one over the other, but that one is superior.

Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.

That's also built into VSCode. The feature is called "Remote".

Not the same, from what I have seen. But, more pointedly, I have been doing this specific workflow for over the last decade.

So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.

> Even if you are an elisp expert, emacs is by now quite inferior to VSCode for most things

Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with.

With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently.

In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.

> emacs is by now quite inferior to VSCode for most things; what you get out of the box with vscode beats laborious customization by expert hands

I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess.

VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it.

From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit.

It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.

I tried typescript lsp in emacs (tide) and it gave me a lot for free (realtime type check, formatting). What else VSCode has ? nicer hints (dom based) and refactoring ? Genuinely curious.

Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.

From my observation, the IDE-parts of VS Code are what put most computers to their knees. VS is very performant when acting like a regular text editor, even better than emacs in certain cases -_-

But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.

That's odd.. tsc doesn't seem to be the issue (I barely notice it on my machine). But I'm no internal dev so maybe.

  emacs is by now quite inferior to VSCode for most thing

I think this statement illustrates a problem that comes up again and again in tool discussions.

I'm pretty familiar with both environments. Objectively there are things that VSCode does very well that emacs is weak at, though you can hack about and get some sort of approximation usually. And there are things that emacs does very well that VScode is weak or nonexistent at, though you may be able to hack an approximation together.

The problem with these discussions tends to be that people fall into camps where they consider other peoples must-have functionality to be irrelevant or unimportant, so "their" tool of choice "obviously" is "better".

This is especially true of something like VScode vs. emacs, where the natural domain of VScode is much narrower than the natural domain of emacs.