4 ms·

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 Em

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?

tshirttime 3y ago
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.
BeetleB 3y ago
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.
- samatman 3y ago
  > 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 https://github.com/buhe/vscode-mail
  - cmrdporcupine 3y ago
    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.

tshirttime 3y ago

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.

BeetleB 3y ago

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.

samatman 3y ago
> 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 https://github.com/buhe/vscode-mail
- cmrdporcupine 3y ago
  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.