6 ms·

I’m genuinely wondering why you would chose VSC over emacs. Granted, I’m on doom emacs and it’s mainly because I’m too lazy to config Neovim, so it’s not like I

by devjab 2y ago

I’m genuinely wondering why you would chose VSC over emacs. Granted, I’m on doom emacs and it’s mainly because I’m too lazy to config Neovim, so it’s not like I’m really a purist. I even use VSC occasionally when I’m in a context on my lovely windows work computers where I don’t have access to WSL, but it’s such a horrible experience. It’s slow, the plugins are ass and the LSPs are horrible for basically anything which isn’t Typescript. I don’t even think VSC is “that” bad despite what I made it sound like, but it’s probably as temporary as any other modern IDE. In a few years “every” VSC user will probably have moved on to Zed. Meanwhile your emacs (or vim) dot files will setup the only IDE you’ve ever used on any machine.

lysace 2y ago
I started using GNU Emacs in the mid 1990s. I like the ergonomics of the interface. It's muscle memory since long. I tolerated the LISP aspect. In VS Code I use the "Awesome Emacs Keymap" extension by Yuichiro Tachibana (Tsuchiya): https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx https://marketplace.visualstudio.com/items?itemName=tuttieee... What won me over? GH Copilot + the overall packaging. It just works. Good, polished UX. Emacs needs to catch up on this front.
- BeetleB 2y ago
  Copilot is available on Emacs, but yes, a lot less polished.
- arrsingh 2y ago
  I've been using emacs for 30 years and have tried VS code several times but the muscle memory on Emacs has prevented me for switching. I've gotten LSP on emacs working well enough but the performance just isn't there. So today thanks to your suggestion I tried it once more with the Awesome Emacs Keymap extension and right away I ran into not having dired mode to switch files. A quick google search got me vscode-dired (incase anyone else runs into it): https://marketplace.visualstudio.com/items?itemName=rrudi.vscode-dired https://marketplace.visualstudio.com/items?itemName=rrudi.vs... Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call extension.dired.open per this stackoverflow: https://stackoverflow.com/questions/62235792/how-to-add-multiple-keyboard-shortcuts-to-one-command-in-vs-code https://stackoverflow.com/questions/62235792/how-to-add-mult... that seems to satisfy the muscle memory... and it seems at first glance that this time the switch to vscode might actually stick. (thanks for the link to the emacs keymap extension) We'll see how it goes! edit: After even 5 minutes of building some rust code I ran into too many issues! I love the syntax highlighting in VS Code and everything else but I have way too much custom elisp to build and debug Rust/Go/C++ and recreating all that in VSCode or learning the new bindings is a bridge too far! I would pay real money to someone who would build an amazing performant experience for emacs. Sigh.
  - iLemming 2y ago
    > LSP on emacs working well enough but the performance just isn't there. Have you tried https://github.com/blahgeek/emacs-lsp-booster https://github.com/blahgeek/emacs-lsp-booster? Also, build Emacs --with-native-comp flag
  - throwup238 2y ago
    Depending on the language you use VScode might not be any more performant because it probably uses the same LSP on top of electron instead of elisp. I write Rust/C++ on a sizable project and since everyone depends on rust-analyzer* all IDEs are just unbearably slow and mostly useless in language integration beyond basic refactors and click to go to definition. * except RustRover but that comes with its own set of issues
    - arrsingh 2y ago
      yes its rust. Looks like you're right. Well is back to good old emacs for me!
      - throwup238 2y ago
        > I have way too much custom elisp to build and debug Rust/Go/C++ What kind of emacs scripts do you write to help debug Rust?
        arrsingh 2y ago
        Nothing special or too sophisticated. On the one hand I use Just (a command runner) to standardize specific build and test commands that call cargo with various flags. Here is a simple example from one of my repos: https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfile https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfi... Then I have a bunch of elisp code that calls just and / or generates boilerplate code right in the buffer - M-x new-macro or M-x run-test (asks for a test to run) etc. I keep writing more elisp as I go along and add specific key bindings to specific things and now its too hard to move away from it all.
- iLemming 2y ago
  > It just works. That "it just works" thing gets me all the time. I just don't get it. Some things surely do work nicely out of the box in a proprietary specialized tool, like for example JS/TS-related things indeed are very nice in VSCode. Just like Java-related stuff works great in IntelliJ. But programming is far more than writing code. I can argue that writing in plain English for a programmer is perhaps far more important than writing in a PL. And for any kind of plain-text manipulation, Emacs absolutely has no match today. Of that, I'm certain, because I have watched and followed many VSCode/IntelliJ power users and long-time users, and I do occasionally use those tools personally as well. There are so many practical example use cases where Emacs just kicks things out of the ballpark - from sending requests to LLMs in the midst of taking notes, to controlling video playback, and annotating PDFs - typing those annotations while browsing the document. And then that "it just works" fallacy. No cookie-cutter solution ever can make a true coder happy. How can one not get annoyed by a bunch of minor, seemingly not-big-of-a-deal issues over a long period of time? Like having to use the mouse for certain operations without a good alternative, or fixed keybindings that can't be fully customized, or the search bar not remembering your last search position and parameters? It's like buying a car with seats at a fixed angle and not even being able to change that. I mean, sure, Emacs may seem dauntingly complex at first glance, but the initial investment in learning this infinitely hackable tool pales in comparison to the countless hours lost wrestling with the unchangeable constraints of less adaptable alternatives. > I tolerated the LISP aspect. I don't know the extent of what you meant by that, but I guess you've "acquired a vehicle," using it to commute and go grocery shopping, and never even realized that you had an actual spaceship all this time. Emacs is most importantly "a Lisp Machine" with a built-in text editor and not the other way around. It is exactly Lisp that makes it so fascinatingly hackable. One chooses Emacs, Lem, Light Table, etc., specifically because of Lisp, not to "tolerate" or "suffer" through dealing with it.
sgillen 2y ago
I switched because all my coworkers use VSC, just easier to have extensions like linters and goto definitions synced, we can help each other with any issues in the workflow. Still use emacs + org mode for notes though, and spent quite a lot of time getting VSC to act like emacs in terms of shortcuts etc.
- BeetleB 2y ago
  > Still use emacs + org mode for notes though, Sounds like you didn't switch, but rather added another tool in your toolbox. The constant comparisons to VSCode frustrate me because they're often presented as "either-or". I use Emacs. And I use VSCode.
  - lucasoshiro 2y ago
    > The constant comparisons to VSCode frustrate me because they're often presented as "either-or" I can say the same for Vim... My primary editor is Emacs, but I use vim if I want to edit something quickly in the terminal (config files, git commits, etc). If the codebase is bigger then I use the JetBrains IDEs... I installed VSCode but I just don't like it. Until today I didn't find a use case for it being added to toolbelt. But I must admit that it almost won the editor wars, people just suppose that you use it.
    - tcoff91 2y ago
      Do you use EViL mode?
      - lucasoshiro 2y ago
        No. I have used exclusively Vim for some time before going to Emacs, and I switched because the package management in Emacs was better and because the plugins were more polished. Then I wanted to do "the official way", using the default Emacs keybindings, even though I find the Vim keybindings better. I switched in late 2015, things were different back then. If it was today I think I would probably jump to Doom Emacs or Neovim.
subjectsigma 2y ago
> It’s slow What? > the plugins are ass > the LSPs are horrible for basically anything which isn’t Typescript What?? I need to edit projects on a remote machine nearly every day. (I do cross-platform Python dev so I need to run and test code on Windows and Linux VMs while working on a Mac.) Compare VSC’s Remote Edit plugin to TRAMP and let me know what you think. For me it’s not even a contest. TRAMP just simply doesn’t work in a majority of use cases and I’ve only had a few small hiccups with the VSC Remote Edit. Getting LSP plugins working over TRAMP on another machine is hell. I just use Emacs for org-mode and Magit now.
- zelphirkalt 2y ago
  This is not a fair comparison though, since you are relying on having some probable non-free software running on the server, while Emacs is able to give you remote editing and keeps your server clean. You would have to compare what VSCode does to running Emacs server side and connecting with Emacs client to the server. Then it would be a fair comparison.
- IceDane 2y ago
  Anyone comparing tramp to Vscs remote editing is delusional, and I say this as an emacs user.
  - otabdeveloper4 2y ago
    VSCode remote editing is a broken piece of shit. [Yeah, yeah, I know, I shouldn't be running NixOS and I should use a Microsoft (c) approved OS instead like all the cool kids. Wake me up in 100 years when Microsoft ceases to exist.]
  - ParetoOptimal 2y ago
    For fully local things like docker containers or across lan, its comparable if you use SSHControlMaster. Also, the emacs approach uses very little resources. This matters if your LSP server takes 80% of your RAM. Vscode takes 20%, emacs/tramp doesn't.
  - subjectsigma 2y ago
shepherdjerred 2y ago
At the very least it's useful to use the tools that your coworkers are using. If you're helping a new grad out you do _not_ want to recommend that they use emacs over VS Code. And, when they have questions about VS Code, it's useful if you can answer them. Maybe you don't have to use VS Code full-time, but having a knowledge of it is useful. Personally, I started using VS Code because support for frontend is much better there than in JetBrains IDEs and it has great remote editing capabilities. I would prefer to use JetBrains IDEs (I did for many years, and I still go back for Java), but VS Code is just better. I would never use Vim for editing full-time, though I do use lunarvim when I need to quickly edit a remote file.
- zelphirkalt 2y ago
  But I am not the Microsoft support guy, or maintainer of VSCode. It happened in the past, that even though I don't use VSCode, I knew how to help someone, but I would never go as far as endorsing it, especially not to a new grad. If anything in the direction, it would be VSCodium, which the no-carers don't even know exists. Other than that, I would tell them they have to make their own choice and if they happen to choose a tool I know, I can help them out, perhaps. If they want to learn Emacs and ask me questions about how I do something, I would be glad to help them learn this freedom respecting tool, over something like VSCode.
golly_ned 2y ago
I use doom too. It’s slow vs VSC for me and doesn’t have a lot of code intelligence actions easily accessible. The LSPs are great for languages I code in, Go and Python.
mardifoufs 2y ago
What do you mean by slow? Like, slow at doing what? I can't think of a specific feature that is slower on vscode. Emacs is actually rather slow...
- cerved 2y ago
  Starting
- ParetoOptimal 2y ago
  Remote access because vscode uses a daemon but emacs uses scp for tramp.
  - mardifoufs 2y ago
    Remote access has been way faster on vscode for me. I'm not sure what the daemon has to do with speed here, if anything it's one of the reason why remote SSH on vscode is so good.
    - zelphirkalt 2y ago
      I think the point is comparing 2 different things. VSCode with a helper daemon running on the server, and Emacs not configured to run as a daemon on the server side, accessing the server via SSH and scp. I am not sure how the speed of both compares, if one properly sets up Emacs on the server as well, to make it a fair comparison.
  - mdaniel 2y ago
    Merely for consideration, ControlMaster gets one out of the business of establishing a fresh ssh session per ssh/scp operation: https://man.openbsd.org/ssh_config#ControlMaster https://man.openbsd.org/ssh_config#ControlMaster (and its friends https://man.openbsd.org/ssh_config#ControlPersist https://man.openbsd.org/ssh_config#ControlPersist & https://man.openbsd.org/ssh_config#ControlPath https://man.openbsd.org/ssh_config#ControlPath )
- iLemming 2y ago
  > Emacs is actually rather slow. It depends on so many different things. Aside from platform specifics (sure, it can be painfully slow on Windows), Emacs might feel slow for various reasons, but it doesn't have to be. Built-in Profiling tools are godsend and if used properly Emacs can be quite impressively fast. My Emacs starts quickly (in less than a second), and it is very pleasantly snappy.
parasti 2y ago
I switched from Emacs to VS Code some years ago after being a hardcore Emacs user for many years. For me it was customization fatigue. Just an endless accumulation of Emacs Lisp one liners and functions that I have no use for outside of Emacs. In comparison, I don't even know where my VS Code dotfiles are. I don't need it to be set up with my customizations, I just use it out of the box and add extensions when I need to.

by devjab 2y ago

lysace 2y ago

I started using GNU Emacs in the mid 1990s. I like the ergonomics of the interface. It's muscle memory since long. I tolerated the LISP aspect. In VS Code I use the "Awesome Emacs Keymap" extension by Yuichiro Tachibana (Tsuchiya): https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx https://marketplace.visualstudio.com/items?itemName=tuttieee... What won me over? GH Copilot + the overall packaging. It just works. Good, polished UX. Emacs needs to catch up on this front.

BeetleB 2y ago
Copilot is available on Emacs, but yes, a lot less polished.
arrsingh 2y ago
I've been using emacs for 30 years and have tried VS code several times but the muscle memory on Emacs has prevented me for switching. I've gotten LSP on emacs working well enough but the performance just isn't there. So today thanks to your suggestion I tried it once more with the Awesome Emacs Keymap extension and right away I ran into not having dired mode to switch files. A quick google search got me vscode-dired (incase anyone else runs into it): https://marketplace.visualstudio.com/items?itemName=rrudi.vscode-dired https://marketplace.visualstudio.com/items?itemName=rrudi.vs... Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call extension.dired.open per this stackoverflow: https://stackoverflow.com/questions/62235792/how-to-add-multiple-keyboard-shortcuts-to-one-command-in-vs-code https://stackoverflow.com/questions/62235792/how-to-add-mult... that seems to satisfy the muscle memory... and it seems at first glance that this time the switch to vscode might actually stick. (thanks for the link to the emacs keymap extension) We'll see how it goes! edit: After even 5 minutes of building some rust code I ran into too many issues! I love the syntax highlighting in VS Code and everything else but I have way too much custom elisp to build and debug Rust/Go/C++ and recreating all that in VSCode or learning the new bindings is a bridge too far! I would pay real money to someone who would build an amazing performant experience for emacs. Sigh.
- iLemming 2y ago
  > LSP on emacs working well enough but the performance just isn't there. Have you tried https://github.com/blahgeek/emacs-lsp-booster https://github.com/blahgeek/emacs-lsp-booster? Also, build Emacs --with-native-comp flag
- throwup238 2y ago
  Depending on the language you use VScode might not be any more performant because it probably uses the same LSP on top of electron instead of elisp. I write Rust/C++ on a sizable project and since everyone depends on rust-analyzer* all IDEs are just unbearably slow and mostly useless in language integration beyond basic refactors and click to go to definition. * except RustRover but that comes with its own set of issues
  - arrsingh 2y ago
    yes its rust. Looks like you're right. Well is back to good old emacs for me!
    - throwup238 2y ago
      > I have way too much custom elisp to build and debug Rust/Go/C++ What kind of emacs scripts do you write to help debug Rust?
      - arrsingh 2y ago
        Nothing special or too sophisticated. On the one hand I use Just (a command runner) to standardize specific build and test commands that call cargo with various flags. Here is a simple example from one of my repos: https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfile https://github.com/deepmesa/deepmesa-rs/blob/mainline/justfi... Then I have a bunch of elisp code that calls just and / or generates boilerplate code right in the buffer - M-x new-macro or M-x run-test (asks for a test to run) etc. I keep writing more elisp as I go along and add specific key bindings to specific things and now its too hard to move away from it all.
iLemming 2y ago
> It just works. That "it just works" thing gets me all the time. I just don't get it. Some things surely do work nicely out of the box in a proprietary specialized tool, like for example JS/TS-related things indeed are very nice in VSCode. Just like Java-related stuff works great in IntelliJ. But programming is far more than writing code. I can argue that writing in plain English for a programmer is perhaps far more important than writing in a PL. And for any kind of plain-text manipulation, Emacs absolutely has no match today. Of that, I'm certain, because I have watched and followed many VSCode/IntelliJ power users and long-time users, and I do occasionally use those tools personally as well. There are so many practical example use cases where Emacs just kicks things out of the ballpark - from sending requests to LLMs in the midst of taking notes, to controlling video playback, and annotating PDFs - typing those annotations while browsing the document. And then that "it just works" fallacy. No cookie-cutter solution ever can make a true coder happy. How can one not get annoyed by a bunch of minor, seemingly not-big-of-a-deal issues over a long period of time? Like having to use the mouse for certain operations without a good alternative, or fixed keybindings that can't be fully customized, or the search bar not remembering your last search position and parameters? It's like buying a car with seats at a fixed angle and not even being able to change that. I mean, sure, Emacs may seem dauntingly complex at first glance, but the initial investment in learning this infinitely hackable tool pales in comparison to the countless hours lost wrestling with the unchangeable constraints of less adaptable alternatives. > I tolerated the LISP aspect. I don't know the extent of what you meant by that, but I guess you've "acquired a vehicle," using it to commute and go grocery shopping, and never even realized that you had an actual spaceship all this time. Emacs is most importantly "a Lisp Machine" with a built-in text editor and not the other way around. It is exactly Lisp that makes it so fascinatingly hackable. One chooses Emacs, Lem, Light Table, etc., specifically because of Lisp, not to "tolerate" or "suffer" through dealing with it.

sgillen 2y ago

I switched because all my coworkers use VSC, just easier to have extensions like linters and goto definitions synced, we can help each other with any issues in the workflow. Still use emacs + org mode for notes though, and spent quite a lot of time getting VSC to act like emacs in terms of shortcuts etc.

BeetleB 2y ago
> Still use emacs + org mode for notes though, Sounds like you didn't switch, but rather added another tool in your toolbox. The constant comparisons to VSCode frustrate me because they're often presented as "either-or". I use Emacs. And I use VSCode.
- lucasoshiro 2y ago
  > The constant comparisons to VSCode frustrate me because they're often presented as "either-or" I can say the same for Vim... My primary editor is Emacs, but I use vim if I want to edit something quickly in the terminal (config files, git commits, etc). If the codebase is bigger then I use the JetBrains IDEs... I installed VSCode but I just don't like it. Until today I didn't find a use case for it being added to toolbelt. But I must admit that it almost won the editor wars, people just suppose that you use it.
  - tcoff91 2y ago
    Do you use EViL mode?
    - lucasoshiro 2y ago
      No. I have used exclusively Vim for some time before going to Emacs, and I switched because the package management in Emacs was better and because the plugins were more polished. Then I wanted to do "the official way", using the default Emacs keybindings, even though I find the Vim keybindings better. I switched in late 2015, things were different back then. If it was today I think I would probably jump to Doom Emacs or Neovim.

subjectsigma 2y ago

> It’s slow What? > the plugins are ass > the LSPs are horrible for basically anything which isn’t Typescript What?? I need to edit projects on a remote machine nearly every day. (I do cross-platform Python dev so I need to run and test code on Windows and Linux VMs while working on a Mac.) Compare VSC’s Remote Edit plugin to TRAMP and let me know what you think. For me it’s not even a contest. TRAMP just simply doesn’t work in a majority of use cases and I’ve only had a few small hiccups with the VSC Remote Edit. Getting LSP plugins working over TRAMP on another machine is hell. I just use Emacs for org-mode and Magit now.

zelphirkalt 2y ago
This is not a fair comparison though, since you are relying on having some probable non-free software running on the server, while Emacs is able to give you remote editing and keeps your server clean. You would have to compare what VSCode does to running Emacs server side and connecting with Emacs client to the server. Then it would be a fair comparison.
IceDane 2y ago
Anyone comparing tramp to Vscs remote editing is delusional, and I say this as an emacs user.
- otabdeveloper4 2y ago
  VSCode remote editing is a broken piece of shit. [Yeah, yeah, I know, I shouldn't be running NixOS and I should use a Microsoft (c) approved OS instead like all the cool kids. Wake me up in 100 years when Microsoft ceases to exist.]
- ParetoOptimal 2y ago
  For fully local things like docker containers or across lan, its comparable if you use SSHControlMaster. Also, the emacs approach uses very little resources. This matters if your LSP server takes 80% of your RAM. Vscode takes 20%, emacs/tramp doesn't.
- subjectsigma 2y ago

shepherdjerred 2y ago

At the very least it's useful to use the tools that your coworkers are using. If you're helping a new grad out you do _not_ want to recommend that they use emacs over VS Code. And, when they have questions about VS Code, it's useful if you can answer them. Maybe you don't have to use VS Code full-time, but having a knowledge of it is useful. Personally, I started using VS Code because support for frontend is much better there than in JetBrains IDEs and it has great remote editing capabilities. I would prefer to use JetBrains IDEs (I did for many years, and I still go back for Java), but VS Code is just better. I would never use Vim for editing full-time, though I do use lunarvim when I need to quickly edit a remote file.

zelphirkalt 2y ago
But I am not the Microsoft support guy, or maintainer of VSCode. It happened in the past, that even though I don't use VSCode, I knew how to help someone, but I would never go as far as endorsing it, especially not to a new grad. If anything in the direction, it would be VSCodium, which the no-carers don't even know exists. Other than that, I would tell them they have to make their own choice and if they happen to choose a tool I know, I can help them out, perhaps. If they want to learn Emacs and ask me questions about how I do something, I would be glad to help them learn this freedom respecting tool, over something like VSCode.

golly_ned 2y ago

I use doom too. It’s slow vs VSC for me and doesn’t have a lot of code intelligence actions easily accessible. The LSPs are great for languages I code in, Go and Python.

mardifoufs 2y ago

What do you mean by slow? Like, slow at doing what? I can't think of a specific feature that is slower on vscode. Emacs is actually rather slow...

cerved 2y ago
Starting
ParetoOptimal 2y ago
Remote access because vscode uses a daemon but emacs uses scp for tramp.
- mardifoufs 2y ago
  Remote access has been way faster on vscode for me. I'm not sure what the daemon has to do with speed here, if anything it's one of the reason why remote SSH on vscode is so good.
  - zelphirkalt 2y ago
    I think the point is comparing 2 different things. VSCode with a helper daemon running on the server, and Emacs not configured to run as a daemon on the server side, accessing the server via SSH and scp. I am not sure how the speed of both compares, if one properly sets up Emacs on the server as well, to make it a fair comparison.
- mdaniel 2y ago
  Merely for consideration, ControlMaster gets one out of the business of establishing a fresh ssh session per ssh/scp operation: https://man.openbsd.org/ssh_config#ControlMaster https://man.openbsd.org/ssh_config#ControlMaster (and its friends https://man.openbsd.org/ssh_config#ControlPersist https://man.openbsd.org/ssh_config#ControlPersist & https://man.openbsd.org/ssh_config#ControlPath https://man.openbsd.org/ssh_config#ControlPath )
iLemming 2y ago
> Emacs is actually rather slow. It depends on so many different things. Aside from platform specifics (sure, it can be painfully slow on Windows), Emacs might feel slow for various reasons, but it doesn't have to be. Built-in Profiling tools are godsend and if used properly Emacs can be quite impressively fast. My Emacs starts quickly (in less than a second), and it is very pleasantly snappy.

parasti 2y ago

I switched from Emacs to VS Code some years ago after being a hardcore Emacs user for many years. For me it was customization fatigue. Just an endless accumulation of Emacs Lisp one liners and functions that I have no use for outside of Emacs. In comparison, I don't even know where my VS Code dotfiles are. I don't need it to be set up with my customizations, I just use it out of the box and add extensions when I need to.