For whose use Emacs and VS Code, when and why you use VSCode? #emacs #vscode

I consider my setup pretty close to the VS Code experience (coding in dart/flutter and typescript/react) without lose the Emacs soul, I'm glad to help everyone to archieve the same. [https://github.com/guilhermecomum/emacs.d](https://github.com/guilhermecomum/emacs.d)

I still use VSCode for most development tasks and Emacs for note taking and simpler text editing (org mode, etc). I have tried to switch to Emacs for development, but it's so fiddly and I'm so set in my ways that I want Emacs to match my workflow, not the other way around. And, I have a tendency to get wrapped up in yak shaving (editing my config) rather than getting work done when something bugs me. Emacs will open a new split when I didn't expect it to and I have to dig in, or I get mad at eshell and decide to configure vterm, but can't get it to work the way I expect it to, or some other Emacs paper cut issue. I dream of someday using Emacs for more, but have found that for now it's better for me to relegate Emacs for simpler tasks so I don't go down these rabbit holes.

VScode for remote explorer and Emacs for everything local. Tramp and LSP aren’t working well together in Doom :/ I develop with Clangd and sometimes I use Python

tldr; Long time emacs user (several decades). I tried to get emacs working with the `gopls` LSP and failed. VSCode just works with `gopls`. ============ I put several hours (perhaps 8 spread over several efforts). IMO the root cause was 3rd party package dependency hell. My co-worker who had gopls working with his emacs on his Mac tried to help me also couldn't figure out what was wrong. I installed the VSCode package for Ubuntu and it all just worked, the way emacs packages that are included with emacs typically just work. For VSCode I installed a plugin with emacs like bindings to make the switched between the two less painful. VSCode plugins are easy to install and just work. E.g. the Go plugin will even ask you to let it install various go tools (gopls, goimports, etc) that it needs. You click "yes" and it just works. I had a similar problem with magit. I had been using it for years but then I switched jobs, installed emacs on my new job's linux laptop and presto, dependency hell I couldn't figure out. By by magit. Yesterday I installed *Git Lens* in VSCode and it just works. (I do still use the built in emacs/git integration which works fine but is not as nice as magit). I mostly code in Go with some tiny bits of Python, Bash and C. For those I use VSCode. I still use emacs to other editing. Heck, I'll even switch from VSCode to emacs to to certain things (e.g. regexp-query-replace).

ot: ad https://github.com/guilhermecomum/emacs.d/blob/main/snippets/python-mode/pdb.yasnippet you can debug with one line like this: `__import__('pdb').set_trace()` or even `breakpoint` (see https://peps.python.org/pep-0553/ )

Shouldn’t you want emacs to match your workflow?

> when and why you use VSCode? When work doesn't really give you a choice of editors. And because of a lack of choice. Before LSP was a thing there was a reasonable need to use certain other editors depending on the language you're working with, but since it has come around it's rather less important (and there were ways to manage before).

I do webdev work on VSCode. I've just never been able to get a good enough experience out of Emacs for web. Web mode is good enough if you're just doing standard html+js+css, but once you move past that with all the elaborate frameworks that exist it becomes almost unusable. There's some exciting progress being made with treesitter and tsx mode, which I am testing, but ultimately I think the pace of development in the javascript world (for good, but probably mostly bad) is just too fast for Emacs to keep up with.

I use Emacs for notes and vscode for most coding. That's what vscode was built for, and it does it well. Emacs can do some programming well too, but it takes more time, is less performant (at least on Windows), and breaks easily. Emacs (like vim/Neovim) also does not have very good tools for working with MS SQL server, which is a large part of what I do. (Also I think Datagrip is much better than vscode or azure data studio for working with SQL server, but I'm not sure it's enough better I want to pay for it personally).

> My co-worker who had gopls working with his emacs on his Mac tried to help me also couldn't figure out what was wrong. I can't help but wonder, has anyone made an issue with the project to either Dockerize or (preferably) package in [Guix](https://guix.gnu.org/)/[Nix](https://nixos.org/) to prevent such reproducibility issues?

I can't get DAP mode to work correctly with my python env setup. So whenever I need to debug python code, I hop over to VSCode.

I use Emacs for note taking mostly. I've been more and more frustrated with the development part of it. Random pauses for no reason when editing code, using LSP and tree-sitter. I'm using Emacs 29 with gcc and all the possible enhancements I know of. It's getting pretty frustrating.

I use emacs for org mode's full feature set, but VSCode for any development.

I kinda go back and forth. Emacs is my main text editor for most things, however for programming, I'm using VSCode more and more these days (with an emacs keymap installed on vscode). I have found that LSP on vscode just works a little better than lsp-mode on emacs, no matter how much I tried to customize the latter. There's something clunky and inelegant about it. On the other hand, vscode tends to be kinda slow on some of the very large projects that I work on.

[deleted]

That's precisely what I said, but maybe it was unclear. *"I want Emacs to match my workflow, not the other way around".* In other words, Emacs should work the way I want instead of me being forced to work the way Emacs wants. Unfortunately, I haven't achieved that in my dev workflow, and Emacs' behaviors at times can be really frustrating. But it's helped me get rid of so many of my other text editor apps/workflows like Taskpaper, Sublime Text, etc.

I took your comment seemed to mean that you “wanted emacs to match your workflow” but felt that such “want” is not correct and therefore stopped using emacs. I’m saying that the “want” you have is perfectly valid and people in general “should” have the same “want” you have

I ran into this exact problem. I got constantly broken by package developers changing APIs and dependencies willy-nilly and things not working. People in "the ecosystem" seem to think users (even technical) have hours to spend filing bug reports on API breakage etc. Sorry, no thanks. Hours of back-and-forth and often the result will be something like "it's not my fault it's package X's fault, just upgrade". Even though I dislike it and am complaining, I believe it's actually fine. People are providing really cool stuff for free after all (eg magit). But it still became not worth it for me personally to deal with the whole `package.el` lifestyle. And I suspect there are many other stories like yours where people just got tired of chasing breakage and moved on. FWIW my solution has been to vendor all Elisp packages (and their dependencies) I depend on in git repos that I control. Upgrades are rarely performed unless something _really good_ happens that's worth upgrading for. In many cases the library updates are not really worth it anyway e.g. "lib X needs to use f.el now" ok fine? but as a user that buys me nothing tbh As a result of vendoring libs i've had literally _years_ of stability. For example, I'm running magit v2.8.0-something and it already does everything I need, so why upgrade? Package ecosystem folk are unlikely to want to hear this but, the juice from getting onto `package.el` and friends kinda isn't worth the squeeze IMO. I'm sure everyone has good intentions, but in the limit all it takes is one `git push` that breaks you, and you're sitting there with a broken system when you need to get your job done. Fundamentally the "upgrade libraries over the network at text editor startup and pray someone somewhere did the MxN integration testing for free" approach is not something I can rely on for real work

When my brain gets a damage and I forget all the keybindings and I'm in a hurry, I go use vscode.

I've switched back to vscode nowadays, the thing i missed the most from Emacs is it's buffer system, way better than tabs and whatnot that vscode uses.

Have you tried Eglot?

I use PyCharm for Python and VSCode for TypeScript (specifically SvelteKit) because I have yet to find an lsp-mode setup that gets me all of features I want from the former (mostly because pyright sucks), or even works at all for the latter (Emacs doesn't seem to want to stay connected to svelte-language-server). I've only put an hour or two into trying those setups, so I'll probably circle back to them some day.

I use both. I edit in Emacs, but use VSCode for various things (e.g. debugging) Whenever I have time, I look into replacing some of the VS Code functionality with something in Emacs. But I don't want to spend all my time on it. If VSCode is great at something, I'll use it. And all debuggers outside of MS products tend to suck. In this case it was a particularly pernicious problem. I'm writing Python code in a virtualenv. Although I can get my Emacs to *execute* code using the virtualenv, I just couldn't get it to debug it properly. I'd get one part of it working and it would break another part, etc.

I only switch to VS Code when there's no mode in Emacs for something I want to use, e.g. I wanted to try astro and there's no mode for it in Emacs but obviously there's an official extension in VS Code. When using it my mind was blown by copilot though - I'd love to see it well supported in Emacs. Funny thing is that I encountered the same issues in VS Code that I have in Emacs as they really were probles of the language servers I used but I always blamed Emacs. I sort of considered switching to VS Code before, amid all the hype and excellent sentiment about it. Apparently though, I'm versed in Emacs world more than I thought even without deep elisp knowledge and am just much more efficient - VS Code always seems to me a lot like first steps with Emacs. I recall someone here on reddit said that Emacs sucks but all the other editors suck pretty much the same. Polishing Emacs for a couple of years already brought to a decent place. Having said all that, I wish I could just instantly learn all the VS Code stuff and instantly configure all the extensions to match what I accumulated in Emacs after all those years as I believe it would make me overall more productive.

As others have said, DAP mode isn't quite where I need it to be, so I use vscode as a visual debugger. Really would love to get that working better in emacs so I can quit needing to switch back and forth.

Working on vue projects (for now, until lsp vue is fixed) or on windows

Does :lsp +eglot use the clangd server on my local computer instead of searching for a clangd binary on remote? I’ll try it then.

I’ve had good results swapping from vscode to emacs for React + TSX using web-mode for a non-trivial codebase. The keys for me were switching to native compilation with native json support, tweaking garbage collection thresholds, and generally following the lsp-mode performance guidance. Eglot in my experience is slightly slower for my codebase, but still works very well.

When working from home, I use Emacs in VS Code's terminal. Works like a charm on Windows. Main development task on Emacs and debug in VS Code.

There are alternative package managers for Emacs which do not require a rolling-release approach to consuming elisp packages. e.g. [straight.el](https://github.com/radian-software/straight.el) [Elpaca](https://github.com/progfolio/elpaca) etc.

Check this out - https://github.com/joaotavora/eglot/pull/637.

I used gopls with emacs on Mac, I use nix-shells for everything basically. Nix has go stuff

I don't use VSCode, and thankfully I don't work with teams that require me to do any work in it. Just to be clear - I have nothing against it, I don't hate it. I chose Emacs because I'm completely content with it. But I still have VSCode installed. And the only time I actually use it is when I accidentally break something in my Emacs config and I need to do a quick edit, and Vim is not enough.

How could your local clangd index remote files?

Thanks for sharing these. Not sure if they existed years ago. I'm glad these exist and people are finding them useful. Not sure if I'd bother switching from my own stable, debugged setup at this point tho tbh Still, thanks. Hope your comment helps someone out on here

I only really use VS code for pair programming efforts.

> I want Emacs to match my workflow you mean VSCode workflow, don't you?

> I had a similar problem with magit. I had been using it for years but then I switched jobs, installed emacs on my new job's linux laptop and presto, dependency hell I couldn't figure out. By by magit. Yesterday I installed Git Lens in VSCode and it just works. (I do still use the built in emacs/git integration which works fine but is not as nice as magit). theres also edamagit for vscode

> But I still have VSCode installed. I used it to look at the things I can steal into my Emacs setup, but I don't think I'm going to use it for text-related tasks any time soon > when I accidentally break something in my Emacs config `emacs -q`, (ma)git revert works for me in such case

bruh what are you talking about these are text editors lmao

Is that an important distinction? It’s about what you’re used to and preference, I think it’s not particularly relevant if it’s also the default of some other editor.

It's getting better over time for me. Sometimes I hit arbitrary hangs, though; today it seemed like using Pulumi's TypeScript bindings crash the LSP server for some reason. But other than that, I quite love developing in Emacs:)

I like to use vscode when I’m working on web dev projects. Mainly because I’m to lazy to set up eMacs for this.

I've started to use both as well. Emacs has been org mode/org roam/notes for 2 years now, and all my python development. I couldn't for love or money figure java projects and maven in emacs so ended up using vscode for that. (Crafting Interpreters jlox interpreter - I don't use java for anything else) And I have DAP set-up for debug but find the local variables/watches a bit clunky, I think it's likely I will use vscode for debugging and would probably then use for coding for those languages where i need to debug. To add to the mix: I did set up vim for latex and that is really smooth, the snippets work amazingly well. It's quick and zathura for PDF display feels seemless.

I know, I do too but sometimes I just get frustrated.

Keep an eye on zed.dev 🙂

> It’s about what you’re used to because it was the default of some other editor?

I have probably 20 different extensions in my VSCode setup including extensive key binding remaps. I’ve definitely bent it to my will. I’ve also successfully used other IDEs like PyCharm and even Eclipse in the past. My workflow doesn’t depend on VSCode, but it sure helps to have something to start with where you only need to customize a few parts of it rather than the whole shebang.

Is DAP bad/inadequate in features, or is the problem just setting up and working out how to use it? I only occasionally have used VSCode when I've needed to quickly debug embedded stuff (PlatformIO) because VSCode just worked and I could muddle through to do what I needed. But I really want to get up to speed debugging from Emacs if it's reasonable. I find using VSCode very aggravating. For sure *mostly* because of my unfamiliarity, but the whole pointy-clicky paradigm is frustratingly slow and clunky. If I need it more often I'll have to get deeper into its keybindings which will help a lot, but I resent spending time learning VSCode because I don't see my future there and it's less universally useful than getting deeper into Emacs, which pays off across the board of activities.

It’s about what you’re used to

Maybe it's because my Python debugging needs have been basic, but I've quite enjoyed `realgud` with `pdb` and the `pdbpp` Python package installed.

VScode for huge yaml files. Emacs for everything else.

I have adopted a similar approach with `use-package` and local submodules in a git repo, although I *also* use Debian's Emacs Lisp packages as they only change once every few years. Elpa packages also haven't broken much for me. I like to understand the code I'm allowing to run on my main system shell, and auditing updates in such a way takes time, so I don't constantly update. I'm not quite sure why the authors of the packages you're using don't use [make-obsolete and other features pertaining to Obsolete Functions](https://www.gnu.org/software/emacs/manual/html_node/elisp/Obsolete-Functions.html) to provide graceful deprecation.

[deleted]

As a professional web developer. I found emacs experience is excellent. Not sure what framework you are using, I'm using vue/react/angular. check my setup, https://github.com/redguardtoo/emacs.d

i suggest you try preconfigured [Doom Emacs](https://github.com/doomemacs/doomemacs) its very good and very lightwheght so you can do alot of cool things with emacs without tinkering to you config file. `git clone --depth 1 --single-branch https://github.com/doomemacs/doomemacs ~/.config/emacs` `~/.config/emacs/bin/doom install`

Pakcage dependency is a sovled problem if you use `pakcage.el`. I use https://github.com/redguardtoo/emacs.d#support-legacy-emacs-versions to create a local repository from install packages. Example: https://github.com/redguardtoo/emacs.d#support-legacy-emacs-versions

I never use vscode

Out of curiosity what's your issue ? I use web mode + lsp-mode on a typescript vue.js project without major issues so far.

When I want to quickly follow a tutorial or join an existing project. I want to make sure everything is setup fine like for other team members before setting up my emacs. It's often quite handy to be fireup vscode to help/work with a colleague, and I use emacs when on my own.

> It’s about what you’re used to one doesn't get used to something just out of nowhere, there has to be a background

Doom’s really great, and I keep trying it from time-to-time, but I find when I want modal editing I’ll just grab vim. What I’d love is something as polished as Doom without all the Evil/bloat. I know you don’t have to use Evil with Doom, but it’s an afterthought and running `doom sync` takes forever and highlights just how bloated it is. A Doom that focused on Atom or Sublime or VSCode refugees would win me over in a heartbeat. For now, I’m pretty happy using Emacs as a place for prose/markup rather than code.

I love your config! To answer your question, I only open vs[codium] for tsx. I use emacs for prose and development, and the only syntax out of the 10+ that I never figured out was tsx. I noticed you use company and lsp-mode. They're great, but my current setup involved eglot and corfu, and tsx is *almost* impossible to be used with those. Typescript.el only involves `.ts` unless I create a derived mode and use tree sitter in its place. tsx-mode is just a glorified bundle of several plugins. rjsx-mode completely disregards tsx. I still have not tried tide, which seems to work (after enabling the company backend for cofu) but react projects just work OOTB with vscode, so I see very little reason to use Emacs for them.

Couldn’t agree more with you an I’ve never enjoyed dev as much as I have in eMacs but vscode has so much behind it it’s hard to ignore. The constant thing with vim and eMacs is “how can I get this or that feature into vim/eMacs” but ever since I reversed the question into making my dev flow “how can I get a similar experience to eMacs or vim from vscode and other tooling” it’s a much better time. Bring on the haters

It's hard to tell, honestly. My 2 main use cases right now are running Go programs and gdb-attaching to postgres instances to debug what my queries are bugging out on. In both cases DAP has given me weird behavior (either attaching to the "wrong" thread in Go or just throwing option=nil errors for gdb). I imagine those are my misconfiguration but I've spent a fair bit of time and still haven't gotten it sorted yet.

It has a memory leak somewhere and gets increasingly slow on a medium sized electron project, didn't quite have the time to figure out where exactly the issue was coming from, but I managed to narrow it down to the vue language server. It *has* been a while since I have attempted to work with it in emacs, so maybe the issue has been fixed.

I'm fighting dap-mode quite a lot atm. I'm using doom, so I didn't have to put a lot into setting it up initially. But figuring out how to write a launch.json (haven't tried VSCode in a long time), finding out what adapter to use, fixing one or two bugs on the way and getting things to do what I want has taken me a while and is still a WIP. Some things straight up don't seem to work (yet). Klunky feels like an appropiate description, too. But in another way compared to mouse-heavy UIs. But I'm fine with lsp-mode getting more attention for the moment.But I'm mostly used to the debugger in IntelliJ-IDEs, so some of my gripes may apply to VSCode as well.Learning a few keybindings is definitely a more time efficient way to gain productivity. And knownig a few bindings doesn't make you deeply invested in a platform.

For programming (typescript) I use them in tandem, as I explain here: [https://www.reddit.com/r/emacs/comments/yyoffi/comment/iwydr91/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/emacs/comments/yyoffi/comment/iwydr91/?utm_source=share&utm_medium=web2x&context=3).

Do you mind sharing your configuration. I would like to try this out. Thanks

The only thing you need to install is https://melpa.org/#/realgud. Execute `M-x realgud:pdb`. For the interactive prompt "Run pdb (like this):", execute the file (with correct Python environment already loaded!) you want to debug after `python -m pdb`, hit enter, and you're off to the races. If you are used to `pdb`, well, it's exactly `pdb`. If you want to use [pdbpp](https://github.com/pdbpp/pdbpp), install it into your Python environment you're using the debugger from and it'll automatically hook itself into `pdb` with no additional setup. The main requirement is that your program has to be executable as an argument to `python -m pdb`, which if you're debugging a package and not a single script means you need a CLI entry point for the package. There's good docs on how to do this (https://python-packaging.readthedocs.io/en/latest/command-line-scripts.html for the `setup.py` way). The Emacs requirement is that for anything non-trivial (not a single script), your `PYTHONPATH` and which Python you're going to call needs to be right. You could either specify the full path to the Python you want, or you can use one of the many packages for managing and setting your current environment (https://melpa.org/#/conda, https://melpa.org/#/pyvenv just to pick two). For a system Python you don't need to do anything.

I understand a big part of the value proposition of emacs is tailoring Emacs to your workflow, but I wonder if a lot of people would do better with trying to figure out the emacs way first because it's easier to do that then jump into building your "vscode workflow". This isn't to say you won't change or customize it, just that you need to be productive quickly and that's likely the shortest path. A lot of people will use Doom or spacemacs in this way where they adjust their workflow to what that framework has set up. I did that, then read EINTR, and slowly made my own vanilla config.

When sharing my screen (on zoom, teams) to show the code ==> VSCode. When working on my own ==> emacs. My colleagues can't follow my emacs action with buffers changing with ggtags + magit + ediff. Then, showing on VSCode for the ease of communication.

I've been using emacs for years but I hardly used any useful modes like flycheck, projectile etc. After a gap of like 4 years from programming, I recently I joined a new startup and everyone uses VS Code. So naturally I also started using VS Code. I love the ease of setting up the plugins like eslint, git lens etc. Love the ease of searching. Love the overall intuitive feature. But sadly I've been so used to using only the keyboards and the key combinations of Emacs, it doesn't feel natural to me. I would still use the native terminal for running shell commands and I would still use emacs for git merge. So now after 5 months, I'm now trying to setup all the emacs modes that I find useful in VS like flycheck with eslint, helm, projectile, neotree etc. And I'm gradually shifting to Emacs. And It feels good. Thanks for sharing your emacs setup. It's nice to know what other useful modes that I might be missing out. I love the way you organised it into sections. Cheers!

After the Emacs update, I'm migrating my config to eglot, flymake and tree-sitter trying to use more built-in packages. web-mode and eglot seems to work fine with tsx.