Emacs "doesn't, however, affect progressiveness as much as freedom. Because of freedom, when faced with a question of using technology that is 1. Non-free, but

Emacs "doesn't, however, affect progressiveness as much as freedom. Because of freedom, when faced with a question of using technology that is 1. Non-free, but objectively better, 2. Free, but objectively worse, the latter will always be picked. Given that most technological progress happens through the mechanisms of capitalism, "free" alternatives commonly lag behind to a large degree." Emacs has a degree of integration and customization ability that VSCode just can't touch, so all this talk about VSCode being "objectively better" is pretty myopically focused on just a handful of things geared towards ordinary developers "who mostly just want to get stuff done". Those aren't the only people in existence, and if Emacs doesn't cater to those it's not because of its philosophy of Freedom, but because it doesn't have enough developers who care to steer it in that direction. Emacs is an editor-creation toolkit which is about customization, flexibility, and power. Making it easy to use for people who don't want to invest much time crafting their own editor with this toolkit is just not a big priority. That said, there are some packages like Prelude, which aim at giving Emacs sane defaults and making it easier to use for beginners (though I've never used any of them, so can't vouch for how well they achieve this aim, and I doubt that any of them would give you a full VSCode-like experience out of the box). To me the biggest weakness of Emacs, but also a strength, is that like a typical large open source meta-project (like Linux, the OS including all the software developed for it, not just the kernel) it's a multi-directional effort of hundreds of volunteer developers each running in their own direction. There are no orders from the top steering in one direction, no army of paid developers to make thorny, decades-old bugs finally disappear. Volunteers will get to those if they're interested, and go the way their own interests take them. It just so happens that the stars aligned so that we have the Emacs of today, given the volunteers of yesterday. If they were different volunteers with different priorities, Emacs would be different, and different volunteers tomorrow may steer Emacs in yet another direction. There is no plan. It's an anthill without a queen, with each ant building what it personally wants. This is why, like mature languages with large ecosystems, like Python, like other flexible editors (ie. vim, with its many plugins), and like Firefox (with all of its extensions) you have packages that "interfere with one another, depend on functionality from other packages that get deprecated, changed in incompatible ways, or removed." You really can't have a large package ecosystem developed primarily by volunteers and not have this problem. People work on what they want to work on, and if they don't want to spend the time maintaining their package or making sure it's compatible with whatever package combination any particular user happens to be using, then there are going to be incompatibilities. But I'll take that incompatibility in a heartbeat for the enormous flexibility and power it offers, especially if the alternative is a meager, inflexible package ecosystem where how I edit is dictated from on high by people who cater to the average developer who "just wants to get things done". If you want Emacs to be something else you either have to be really good at herding cats, do it yourself, or pay someone to do it for you. Even then, you'll have to somehow convince all of its users to switch to your "improved" version. Good luck.