10 ms·

Since I only use VSCode (or Codium...), what sorts of things would be in the latter list?

BeetleB 3y ago
Can I use VSCode to: - 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-problem-with-emacs-and-org-mode/ https://blog.nawaz.org/posts/2023/Mar/solving-a-scraping-pro...
- cmrdporcupine 3y ago
  TIL about mastodon.el and now I'm off to MELPA that hot stuff.
- samatman 3y ago
  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
cyrialize 3y ago
Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code. 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-extension https://code.visualstudio.com/api/get-started/your-first-ext...
- tom_ 3y ago
  This is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly. 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.
logicprog 3y ago
Check out org mode (very complex and advanced task management / todo list system, calendar, etc), org roam (basically all the features of Obsidian), the ability to act as an email client, having a cross platform system shell independent shell (in elisp), and of course just general emacs architecture things like the ability to hot reload and replace and debug and inspect and get docs on and add to and modify every part of the editor
Jtsummers 3y ago
I don't think there's anything that's technically not-doable in VS Code that emacs can do. For me, it's more about ease of use that differentiates the two. Specifically around extensions. https://code.visualstudio.com/api/get-started/your-first-extension 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.

Can I use VSCode to: - 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-problem-with-emacs-and-org-mode/ https://blog.nawaz.org/posts/2023/Mar/solving-a-scraping-pro...

cmrdporcupine 3y ago
TIL about mastodon.el and now I'm off to MELPA that hot stuff.
samatman 3y ago
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

cyrialize 3y ago

Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code. 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-extension https://code.visualstudio.com/api/get-started/your-first-ext...

tom_ 3y ago
This is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly. 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.

logicprog 3y ago

Check out org mode (very complex and advanced task management / todo list system, calendar, etc), org roam (basically all the features of Obsidian), the ability to act as an email client, having a cross platform system shell independent shell (in elisp), and of course just general emacs architecture things like the ability to hot reload and replace and debug and inspect and get docs on and add to and modify every part of the editor

Jtsummers 3y ago

I don't think there's anything that's technically not-doable in VS Code that emacs can do. For me, it's more about ease of use that differentiates the two. Specifically around extensions. https://code.visualstudio.com/api/get-started/your-first-extension 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.