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.

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.

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.

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.

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.

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.

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.

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.

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.

Emacs discussions on HN are always unsatisfying, because everyone seems to want to compare it with IDEs or other programming editors.

Only a small portion of the article is about SW development.

The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is. Comparing it to VSCode is meaningless to them. Kind of like having a discussion about PCs, and having people repeatedly talking about how iPods are better. Yes, lots of people use PCs to listen to music, but the comparison is rather silly.

I maintain many files of notes;

I rename files and view directory listings (using Dired);

I pass command lines to Bash to be run. (End of list.)

More to the point, whereas vscode would prove a mostly satisfactory replacement for Emacs for editing and navigating code, it is unlikely I will find a mostly satisfactory replacement for Emacs for the tasks listed above. (And I have been looking: I evaluated for example the most likely of the recent spate of vscode extensions for maintaining notes in markdown files.)

(I don't like keyboard-only UIs; like 68.1% of the Emacs users who responded to a recent survey [1] I never use a terminal or terminal emulator to interact with my Emacs.)

I guess I should explain why a terminal app such a Gnome Terminal would not be a mostly satisfactory replacement for Emacs for submitting command lines to Bash. Like at least one other participant [2] in this comment section, I appreciate being able to use the same set of operations on the output of the Bash process as I use on any other file being edited (without my first needing to copy the output from my terminal app, then paste it into my editor). I also appreciate the fact that the Emacs Lisp code that runs when I send a line of code to Bash is vastly easier to modify than Gnome Terminal would be.

[1] https://emacssurvey.org/2020/

[2] "I really like being able to move about the terminal field as if it were a text file" in https://news.ycombinator.com/user?id=jonnycomputer

The article, is, however written by a software developer.

>The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.

Do we have any hard data here? Or is this just an anecdote?

Sure, Emacs is usable for a lot of stuff outside programming. I personally use it for org-mode and as a general-purpose git client. That doesn't mean that the Emacs usability story could be better overall. Obviously I don't think Emacs should be as narrowly focused as VSCode. Greater usability would benefit users who don't program.

55% according to the Emacs survey 2020 (obviously, take it with a pinch of self-selection bias due to the survey being self selecting).

[1] https://emacssurvey.org/2020/

91.4% of Emacs users use it for coding (so the overwhelming majority, as you'd expect), and then some of them use it for something else.

Those groups are not separate, if you look at the percentages, they add up to a lot more than 100%. So people could check multiple options.

All this tells us is that:

A) Emacs is primarily used by devs (hardly surprising :-) )

B) The devs that use it also use it for other side tasks (also hardly surprising, considering Emacs' kitchen sink philosophy).

> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.

Whether it was used by developers or not, didn't have any bearing on the question/data.

I don't know whether I would draw the conclusion they primarily use it for coding or "other tasks" from the graph; for example a developer using Emacs for `org-mode` only with the occasional git usage would check both boxes.

Just as you've reached the conclusion that 90% means all of them use it primarily for coding, an equally valid conclusion is that 50% use it primarily for /not/ coding.

I don't make that leap - but it seems strange to discount one possibility heavily it favour of another; could you elaborate why?

> The fraction of Emacs users who use it primarily for things other than programming is a lot bigger than most HN readers think it is.

I didn't claim most users don't use it for SW development. I didn't even claim most users don't use it primarily for SW development. I said the number of people who primarily use it for other stuff is larger than most people think.

If HN thinks the number is 5%, and in reality it is 20%: The survey does not have data either way.

And as I noted in another post: The survey is flawed in that it didn't contain a representative sample. In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.

> In particular, people on the Emacs mailing list were quite opposed to filling out the survey, and one of their concerns was what is happening right here: People drawing conclusions from a very poorly executed survey.

But the outcome here is that their point of view was not represented, flawed though the survey may be.

My comment had nothing to do with usability. I merely find the incessant comparisons with VSCode to be (mostly) noise. I'm not even here to advocate for Emacs (although I love it). People want better usability? Fine. But let's not let SW development be the benchmark for how good Emacs is. It's just one use for Emacs.

> Do we have any hard data here? Or is this just an anecdote?

Very much an anecdote. Thing is, so is any other perception. There is no hard data out there. Having said that, hang out on places like the Emacs subreddit and quite a lot of submissions are not related to SW development. Looking at it right now, only 3 submissions on the front page are related to coding/SW. If you follow the weekly Emacs news, you'll similarly find that the bulk of it is not related to coding/SW.

Not really, because it doesn't have all the numbers for built-in features. As you noted: A huge number of users use Emacs for org-mode, which is built in, and many don't feel the need to upgrade org mode often (I myself upgrade it once every year or two).

Also, the sets overlap. Those who use, say, lsp-mode may also use mu4e. That lsp-mode may have more downloads doesn't mean a given user used it more.

I myself use Emacs for SW development. Yet the bulk of my Emacs usage is not SW development. It's mail, tracking TODOs, writing notes, keeping track of things, etc.

> Do we have any hard data here?

https://emacssurvey.org/2020/

I actually find the opposite. As much as I dislike the clumsy GUI, I just keep coming back to Emacs for some things, for the sole reason that it's easier in Emacs. I find Emacs to be the easiest way to customize my text editor, and that's what makes it easy to get my work done. I've tried VS Code many times and I just don't see what's special about it.

OTOH, I have no problem believing someone using Emacs as a daily driver for years would find it easier (but I think most developers, and particularly newer developers—where the JS to Lisp familiarity ratio is much higher than for, say, those who got into coding in the 1980s or earlier—are going to more productive more quickly with VS Code.)

For example, I'm sure VSCode does git but does it as well as Magit? Everyday things can be done on muscle memory, most other things are much more discoverable than I've seen in any git interface (using other git interfaces is like walking in a office with your eyes closed vs open with magit). http://emacsrocks.com/e17.html

I'm sure VSCode does notes too but does it as well as Org mode? Org mode for me is an extension of my brain: it is a working memory that supports executing whatever task I do, it helps organize/automate tasks, it helps focus, etc. For people with ADHD like symptoms, I expect a life changing experience thanks to Org mode -- while other people should just become more productive in it.

Every keystroke is a programmable command in Emacs. VSCode is close. I expect parity for programming modes. Most Emacs interactions are likely less pointy-n-clicky compared to VSCode: somehow pressing keychords steals my focus less than doing actions with a mouse for everyday things freeing the conscious brain to work on the task at hand. Emacs provides a unified interface for me e.g., searching/filtering lists https://writequit.org/denver-emacs/presentations/2017-04-11-...

Emacs doesn't do web browsing very well. I have to survive with Vimium. Does VSCode perform better here?

VSCode is much more popular today. Emacs is GPL -- I expect it to be there in 20 years too. I won't trust Microsoft long term.

VSCode does not even have keyboard macros. Either "every keystroke is a programmable command" is not exactly what is going on in VSCode, or the VSCode users do not exactly understand what this "Open Source" thing is, because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490

https://marketplace.visualstudio.com/search?term=macros&targ...

> Either "every keystroke is a programmable command" is not exactly what is going on in VSCode

There are commands (JavaScript-Functions) which one can be bind to keys. But who knows whether all keys have a command behind them? An with a GUI, I wondern whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.

> because so far there has been 5 years of whining and 0 patches: https://github.com/Microsoft/vscode/issues/4490

Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.

Here is the documentation that explains keyboard macros: https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...

> But who knows whether all keys have a command behind them?

Yes, they literally do in Emacs. That is the whole point of this discussion.

> An with a GUI, I wondern [sic] whether all interactions are bindable commands. Mouse-Interaction, especially in context of some widget might be more complex to handle than just recording an input-flow.

Mouse events result in commands. You can record them as part of keyboard macros, although I have never had a need to do that and cannot think of one.

> Which only means it has no priority. But considering there are 4.7k open issues and 103k closed, taking a single issue is just a hint that the community is likely not pushing hard enough for this specific issue.

Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.

Seems you were to lazy to look deep enough...

> Let me explain how this "Open Source" thing works: you can submit a patch, you don't need to "push hard" on Daddy Microsoft.

Kinda funny how you have no clue how Open Projects are really working. Yes, Submiting a patch is an option. You can do that for VS Code too. Just nobody seem to have done this in this case.

And here comes into play how projects really work, even open source-projects. People complain and except the dev to implement something and than call it a day. And sometimes you have people doing some halfassed crap that makes more problems than it solve, and devs are not obligated to accept the patch. Any partly decent open source-project is doing this. Funny Uncle Emacs is doing this all the time. There is absolutly no difference in how both projects are working.

VSCode is open source, too. There are forks with the Microsoft IP removed from it. I believe Eclipse and RedHat maintain one now as well.

Other than that I basically agree with you. I much prefer Emacs to VSCode, but there are annoying things about it that mean I don't want to use it full time.

2. Did your journey into computing start with CLIs, TUIs, GUIs?

2. It started in the 1980s, back when GUIs were considered a luxury upgrade for the wealthy. This was the first computer I ever owned: https://oldcomputers.net/trs80pc1.html

I'd say the biggest reason for the difference is because (by my understanding) you use JSON for configuration and write functions to extend VS Code using Typescript. I've never been a web developer and I've done very little with Typescript (and not much more with Javascript). OTOH, I've been using Lisp in various forms since forever. For me to pop open my .emacs, add an interactive function, and start using it is usually a couple minutes at most.

Now I think most users of VS Code probably feel more comfortable with Typescript and JSON, but Emacs for me is just a dead easy thing due to my ability to customize tasks almost trivially.

I think the concurrency problem is solvable given tremendous time and effort. However, I doubt there is anything that could be done about defadvice. For all its shortcomings, defadvice is a defining feature of Emacs that makes it more extensible than any of the competition.

That said, yes, I think packages should be (at least) discouraged from using it. A highly dynamic and patch-able software system is a huge asset IF you're the only person working on it, which is true for my own emacs config. But having third parties simultaneously monkeying with the same component without knowing about each other is certainly a recipe for instability, even indeterminism.

Commercial developers have many internal discussions, with the difference that they will not show it to you.

Sample size = 1.

There is a long standing effort to have it merged into emacs/elpa, so we hope the situation will improve.

https://github.com/jwiegley/use-package/issues/282

I just have a strong dislike of bureaucracy, form-filling, and being "on file" somewhere.

Otherwise, package-list-packages and customize are awesome. The interface isn't even that clunky, and it's more powerful than equivalent interfaces in other software. Particularly customize, I'm very impressed by how it works.