Since I only use VSCode (or Codium...), what sorts of things would be in the latter list?
- Read and reply to my emails?
- Manage TODOs across domains (so e.g. I can make a TODO that has a link to a specific email)?
- Use it as a Mastodon client (read and write toots, boost them, favorite them, etc)
- Scrape a web site (several pages), getting only the relevant content[1]
- Bulk rename/copy lots of files with a custom naming algorithm
- Chat on IRC
- Use it as a spreadsheet
- Do numerical integration with it
- Have a literate document with code in several languages that talk to one another
- Annotate PDFs
This is a tiny list. In fact, you can browse past Emacsconf talks to see how people use it.
[1] https://blog.nawaz.org/posts/2023/Mar/solving-a-scraping-pro...
> 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.
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.
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.
I took pains not to do that in either post I made.
> 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.
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!"
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.
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.
https://code.visualstudio.com/api/get-started/your-first-ext...
That's the VS Code description on how to start writing extensions to VS Code. The first steps involve installing node.js so you can install another tool so you can generate scaffolding.
In emacs it would be:
Step 1: Open emacs
Step 2: Open a scratch buffer (q&d extensions, put in a .el file if you want to preserve it)
Step 3: Write some lisp code
Step 4: Evaluate the lisp code
Step 5: There is no step 5, use your extension
Caveats:
You have to learn programming to extend either of them so that's a common burden.
You have to learn lisp to extend emacs, but that's an easy thing to do.
You have to read the documentation to really get going with extension development, another common burden.
In VSCode, I don't think there's anything like "place code in this file, run it at startup, and code within this file can be present/applicable everywhere". Maybe you could do something as a plugin, but that is a big lift compared to Emacs.
For example, think about doing a "Hello World".
In Emacs, you just open init.el and place `(message "Hello World!")`.
In VSCode, you have to follow a whole set up for an extension [0].
[0]: https://code.visualstudio.com/api/get-started/your-first-ext...
If you can do this in Visual Studio Code, it was not at all obvious how when I was looking. There's seemingly no way for you to add any code that executes in the editor's VM without literally restarting the process with your updated code in place. (Visual Studio suffers from a very similar problem.) 2 or 3 restarts is just the beginning! You'll need that many just to be sure you've got all the boilerplate in place.