I think it's fair to say that most people don't need, or even want, their IDE/text editor to do a bunch of stuff that can be done with other programs. I know Emacs people like it (I was, at one time, an Emacs person), and that's great, but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha. Sometimes you want to buy your dessert topping and floor wax in separate cans, y'know?

Emacs is the can class, not two can instances. The power comes from a single can interface, and leveraging one's can-fu across multiple tasks. Also, everyone enjoys some foot cheese in their whipped cream.

Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?"

> but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha.

It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there? The bulk of PC/laptop users use Notepad as their editor, and have no use for VSCode's capabilities. Shall we dismiss all the cool things in VSCode for it?

And sorry, what? Non-editor stuff? About half the items I listed are editor related.

> Sometimes you want to buy your dessert topping and floor wax in separate cans, y'know?

True, but wouldn't it be at least nice if you could buy both cans from the same store, using the same currency?

No one's arguing using only one tool. As I write this, I have both VSCode and Emacs windows open. Use the tool for its strengths. But blanket comparing VSCode with Emacs is silly - it's like comparing Excel with all of Linux. One is an application. The other is a platform. Excel is easily the best spreadsheet out there, but for many people, Linux is much more useful than Excel.

> It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there?

One, I wouldn't have conceded the crown to VSCode so easily as that. A fine-tuned Emacs config, with the requisite muscle memory and custom elisp, is a hot rod. I do use VSCode, and before that Sublime, but it was under protest, the details don't matter here but there were features I needed and no task budget for provisioning them in Emacs.

Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode. For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.

"Emacs does everything" is an aesthetic, and it has many decades of refinement, and people like it. That's fine.

> Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?"

This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.

There's such a thing as a like-for-like comparison. Emacs has org-mode, it has SLIME, it has paredit and parinfer. Those are all edges over VSCode, whereas checking email isn't. This conversation piqued my curiousity, and indeed, there's a plugin for that[0], a few actually, and yes, I'm sure Emacs does a better job, for some value of better. But I'll never know, because I don't intend to use either tool for that job.

[0]: https://github.com/buhe/vscode-mail

The reason some people, including myself, like to do things like email or irc or whatever inside emacs is because we got hooked on the powerful text and buffer management facilities in emacs, and want them everywhere, and consistently.

All these things we're talking include editors in their separate applications. They just use the default OS editor widget using CUA bindings or whatever. Pulling them into emacs turns that on its head, and brings with it all the power (and weirdness) that comes with that.

It's not for everyone, but it's also not something that it's fair to make fun of or dismiss outright.

In the end, what the emacs nerds are doing is remaking the world of Lisp machines, but compromised and/or modified for the environments we have now. Not everyone digs that. I kind of do.

Just that something is largely written in Lisp, doesn't make it a "Lisp Machine", nor a clone of it.

> but compromised and/or modified for the environments we have now.

I would think that GNU Emacs is also compromised by its own design decisions, starting in 1984, when RMS rewrote Gosling Emacs.

> not something that it's fair to make fun of or dismiss outright

I took pains not to do that in either post I made.

> Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode.

I agree it is irrelevant to your use of VSCode. The comparison, though, was for VSCode with Emacs. Not "VSCode with Emacs for samatman's needs".

> For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.

It's illogical to say that Emacs has to be better than all those tools to use them. We're not enforcing a dichotomy. You can use both. You can use Gmail's web interface and Emacs mailing abilities. All you need is for one to have some capability that the other doesn't, as opposed to having every capability the other has.

Next: A large part of my point in this thread is that comparing VSCode to Emacs as a whole is in itself silly - one is a fairly specialized tool and the other is fairly generic. If you want to reduce the discussion to SW development, then fine. But people (not you) blanket saying VSCode is better (or worse) than Emacs is like saying Excel is better than Linux. I don't have any desire to convince someone to leave VSCode for Emacs. What for?

Next: Implicit in your comments is the notion that stuff like reading mails is an "extra" in Emacs. It's artificially categorizing. Reading email in Emacs is not an addon - it's part of Emacs's capabilities (although you may get better experiences than the default with addons). If reading/writing emails is considered "extras", then keep in mind so are things like syntax highlighting, debugging, compiling, etc. Emacs is a text editor, and all those features are addons - at the same level as reading mails.

As a VSCode user, some of these addons mean more to you, and you don't care about the others, but understand that lots of people do care about them. So many people out there use Emacs only for org mode and magit.

> This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.

Context matters. Understand that my list was in response to "What can Emacs do that VS Code can't?" If someone asked "What can Perl do that awk can't?" then mentioning CPAN and Web servers is totally appropriate. It's pointing out that if you learn Perl, it may benefit you far more than awk ever could. Whether it would or not depends on your goals, of course.

> There's such a thing as a like-for-like comparison.

Agreed, but it helps if the scope is stated clearly. More often it's "Why do you use Emacs when VSCode exists?" And then of course, I'll list all the things I do in Emacs that VSCode doesn't provide. If someone asks "Why do you shop at Walmart when you can shop at Whole Foods?" it's not a problem to respond with "Because I can buy electronics at Walmart." You wouldn't jump on him and say "Hey, you're not doing a like-for-like comparison!"

While I, an inveterate emacs user, largely agree, you're not going to change any minds when the debate topic is "Vim and emacs both lost to vscode in the editor wars." To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing.

If emails is considered extra, then so are things like syntax highlighting, debugging, compiling, etc.

Yeah no. The first is email, the latter three are directly relevant to program editing.

> you're not going to change any minds

I am repeatedly accused of this. Consider what I have written:

> then by all means - VSCode is the superior tool.

> No one's arguing using only one tool.

> As I write this, I have both VSCode and Emacs windows open.

> We're not enforcing a dichotomy. You can use both.

> I don't have any desire to convince someone to leave VSCode for Emacs. What for?

I certainly won't change any minds, because I'm not trying to.

> To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing.

While I can agree they are the majority, this is a strange take. Do HN readers come to the site to reinforce their problematic views?

And do you think Emacs submissions often hit the front page because those upvoting view Emacs as "just a programmer's editor"? Quite a lot of these top voted submissions (the majority?) are not about programming.

> Yeah no. The first is email, the latter three are directly relevant to program editing.

You are welcome to whatever hierarchy you wish. From an objective architectural standpoint, all are extras on equal footing. I suppose perhaps some of these may have extended support in the C code, but otherwise they are just elisp libraries on top of the core.

TIL about mastodon.el and now I'm off to MELPA that hot stuff.