[koz_]

I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.

VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily), one that is familiar to all users, even those who might prefer a more idiosyncratic and keyboard-driven interface. This is analogous to how Java facilitates a certain style of OO programming that is familiar to the vast majority of programmers, even those that may prefer and see value in other, less popular / accessible modes of programming.

By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.

This is not to say that Emacs can't or shouldn't be made easier to use, just that I don't think its survival depends on it catching up to editors like VS Code which I perceive as being for a different purpose altogether. I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.

I'd love to be wrong about that, though, and one day get the best of both worlds.

[joseph]

> I agree that VS Code is easier to edit code in, but Emacs is easier to program and extend. Ease of use simply isn't why people use Emacs and I think that at this point it would be hard for it to ever compete with VS Code on that front.

I don't program in Emacs except to fix bugs or make small modifications to my init.el. I use Emacs because it's the easiest editor to use. The keybindings are ubiquitous: they are standard in the command line of bash and other shells as well as numerous other programs, and all throughout the macOS GUI. By sticking to Emacs as an editor I am using the most widely available keybindings anywhere and that helps me be productive in a multitude of places. Emacs has modes for all the languages I use, and especially now with LSP, they generally Just Work. I start Emacs as a server when I log in, and I can connect to it from any shell on the same machine, and my open files are there waiting for me. I guess you might find VS Code better if you like the mouse, but I don't want my hands to leave the keyboard while editing as I find it counterproductive.

[jolux]

I will also add that I think Emacs is a better text editor than VS Code, and easier to edit code with. What I don't think it's better at is intelligent autocomplete, live static analysis, etc. It turns out I value those things more than I value having a hyper-flexible text editor, but that doesn't mean I don't miss the flexibility when using VS Code.

[AlchemistCamp]

> the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.

This is actually how I feel about VS Code! I'm a VIM user (both in and out of VS Code), and there are things I regularly go to MacVim for that the VS Code plugin doesn't support.

The thing that keeps me coming back to VS Code isn't the quality of the editor or the quality of any one thing. It's the quantity of "good enough" plugins and its integration of a good enough terminal.

[jolux]

>I do, however, somewhat suspect that the crucial difficulty of Emacs comes from its messiness, from the huge number of people writing interesting extensions in it, and how they don't always quite play nicely with each other without a bit of glue code.

There's no excuse for Emacs to be as inaccessible as it is though. What is "crucial difficulty?" You write an awful lot of words to excuse why the world's most powerful text editor does not have a high level of polish or usability out of the box. Usability is not at odds with power: it's complementary. The rich extension ecosystem is amazing, and there are tools in it that cannot be had anywhere else (Magit is my git client for everything, even when using IntelliJ and VSCode). But the number of extensions that exist to fix bad and/or obsolete defaults, and the number of extensions that add basic usability improvements, is really high as well.

I'm not advocating for eliminating what makes Emacs Emacs. I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power. In short: I don't believe its messiness is an inevitable effect of its power. I think it's a product of the attitude that certain things about it should suck to weed out users who don't fully agree with its ideology.

>By comparison Emacs would of course be the Lisp of text editors. One could try and make Lisp as accessible and nailed down as Java, after all its extreme customisability lends itself to that, but at that point you'd just be writing a poor man's Java instead of Lisp.

I say this as an OCaml and Elixir programmer: there's nothing wrong with writing Java. The world runs on Java, not Lisp. Statistically speaking more Emacs users probably use it to write Java than any other programming language. If we're not going to meet the world where it's at, we will fail eventually.

[xfer]

> I'm advocating for improving the out-of-the-box usability story so that the editor isn't putting people off before they get a chance to understand and experience its power.

There are atleast a couple of projects like spacemacs and doom-emacs that already do that. The problem with the point you are making is someone has to do that hard work and also need to market it to the beginners. There isn't any money to make Emacs friendly to beginners. So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.

[jolux]

>There are atleast a couple of projects like spacemacs and doom-emacs that already do that.

Both of which are not really true to the core Emacs philosophy in several ways though. And thus, they add a whole new layer to have to debug when something breaks.

>So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.

But there are plenty of open source projects that succeed at usability despite having different people working on different goals. The question is whether we want Emacs to be the best text editor for everyone, or the best text editor for an elite few.

>The problem with the point you are making is someone has to do that hard work and also need to market it to the beginners. There isn't any money to make Emacs friendly to beginners. So i doubt it's ever going to be better than it already is through collaborative efforts of people with different goals.

Of course someone has to do this work, but how hard did Microsoft market VSCode? VSCode's rise has been fueled by word of mouth and strong first-party support for popular tooling. "Marketing" in this case is overstated. You need a product good enough to sell first.

I'm not at all denying this would be a lot of work, but I think it's worthwhile. If you think it's a problem that work is not being done in this area then we don't disagree.

[oblio]

> The question is whether we want Emacs to be the best text editor for everyone, or the best text editor for an elite few.

I can answer that for you. Emacs definitely wants B). They might pay some lip service to A), but as usual, keep your eye on what people do, not on what they say.

To offer a comparison point, Neovim. Neovim is also an Open Source project, but it wants to make Vim more powerful <<and>> more user friendly. So they've removed obscure stuff, made the default configuration newbie friendly, etc.

Emacs is too afraid of this. It has a ton of long term users that just don't want their defaults changed. There's a reason this XKCD is about Emacs: https://xkcd.com/1172/

I think Emacs will change over the following decades. Not because its users will <<change>>, but because its <<users>> will change. To clarify, it's like that saying about science: science advances, one funeral at a time.

[hvis]

> It has a ton of long term users that just don't want their defaults changed.

For all we know, there might be just a dozen of them, but with the (low) popularity of the mailing lists, they are certainly making themselves heard.

> I think Emacs will change over the following decades. Not because its users will <<change>>, but because its <<users>> will change. To clarify, it's like that saying about science: science advances, one funeral at a time.

Right. Hopefully it won't alienate the newer generations of users too much by that time.

[slightwinder]

> but Emacs is easier to program and extend.

That is only true for the low level tasks out of the box. Adding a simple command is very easy. But doing something more complex can be very painful in emacs.

VS Code on the other side is out of the box focusing on flawless experience and supports hacking only through hidden paths. Though, install a simple extension and it's as simple as emacs. While having still a better experience on more complex tasks.

> VS Code is like the Java of text editors. It relies on a universally understood and accepted model of editing text (non-modal, leveraging the mouse heavily)

This again is just the out of the box-experience. Modal editing is possible, though it's true that there is still place for improvments. Which is ok for an editor which is just 5+ years old. The project seems to play a strategy there it unfolds from a safe corridor of stability and adding more and more abilitys, instead of starting from open chaos and trying to control it.