[kiaulen]

I'd argue this is a feature more than a bug. I haven't done much with VSC, but I have done a lot with both atom and emacs (via spacemacs). How do you find out even the name of what you are looking for to find it on the wiki? Is that snippet of elisp tested (or even testable?) What does it do exactly? Is it a passive effect, or something you have to execute a command to run?

In atom, you can find packages on the website or in the dedicated search in the editor. Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.

Emacs is awesome, and currently more customizable than anything else. Tramp and Magit and Evil are best in class. But it's super difficult for a newbie to get started, and the windows compatibility is only so-so.

If you really want to just use code snippets to customize atom, you can! They have an init file for code changes, and a css file for style changes. There's even a website where you can find some of these little scripts: https://www.atom-tweaks.com/

[didibus]

I've found it way easier to customize Emacs, and you can do so much more. Though Atom has pretty great customizability also. This is not true of Visual Studio Code, which has much stricter plugin points.

That said, I know Lisp as well as JavaScript. Obviously, more people know JS, so might find tweaking Atom easier.

In emacs though, I don't even need the internet to figure out how to customize things. C-h is all you need. There's a book bundled in, all functions and variables have amazing built in documentation. You can search for any binding, function or var by regex, go to their code, read their doc, redefine them at runtime.

The only place where Atom wins for me is in theming.

At the end of the day though, I had to go back to Emacs for performance and memory footprint reasons. Atom was just too slow, and used up too much memory.

[meko]

For a newbie you only need to navigate, copy/paste/delete. Then you learn how to manage (multiple) buffers. It took me about a year of regular use to really feel like I could "use" emacs. Full disclosure: emacs fan. Once I started getting used to lisp prompt (M-x) or w.e its like a portal opened up to another level of understanding, realizing that you can write and execute elisp functions from right there in the editor: ex. `replace-string` or `rot13`. it has a great undo system (multiple undo histories) and a effectively unlimited copy paste delete history. search ( C-s ) is also a pleasure to use. Magit is on a whole diff level and offers the most comprehensive and organized git interface I've ever seen shy of CLI git. And all these things are interacted with common controls, so knowing the basics from the beginning of my comment opens up the rest of the fancy stuff relatively quick.

[anamoulous]

> Popular packages get featured, so you can hear about things you wouldn't even know to ask for. Instead of static code, you get free updates whenever they're available. The code in most packages is tested. All the information on how it works is in the Readme.

Sure, and Emacs has this with MELPA (And Atom with... whatever they have). It's great paradigm and all editors should have it.

But I'm not talking about thousands of lines of copied elisp. I'm thinking about molding your editor to fit your needs. Here's an example:

We use hosted Gitlab at work. I like to highlight a line in my editor, call a command in the editor and get a URL for that line in that file in that branch on our internally hosted Gitlab server (with a custom path segment prefix). This is literally maybe ~40 lines lines of very compact elisp in a global configuration file. It would probably be less in JS because I'm better at JS than elisp. It's very specific to my circumstances and doesn't really need to be generalized to anyone else.

There are ~5 different plugins in the marketplace that purport to do this, but none of them fit my use case. Which is fine, I can do this myself...

However to do this vscode I have to create an extension, edit the package.json to register the command and few other things (this is tedious, believe me), re-read/remember the plugin API, re-read/remember how to build vsix files for production, install that plugin with the command line tools, reload vscode.

If I need to make a change, do it all again. But there is no reason that the Emacs behavior couldn't be included in vscode. And maybe some day it will. But the idea that not having it and claiming that is a _feature_ or (as others have done) claim that emacs is losing to vscode in configurability misses the multitude of use cases that emacs users have benefited from for decades.

As far as testing and code quality goes, I can't really argue with that but neither can vscode users? Do you know what all your plugins are doing in the background? All of these centralized plugin repositories are significant attack vectors. Which language do you think the first big own will be written in?