- VS Code has wonderful support for multiple cursors (see https://spin.atomicobject.com/2019/04/04/vscode-multiple-cur... for an example)
- VSC has a lot of the same ideas as Emacs, but they're called different things and the keystrokes are different. Cmd-P "terlogremo" <enter> opens the file "terraform/logging/remote_state.tf" in the current project. Ctrl-g 20 <enter> goes to line 20 in the current file.
- VSC has a lot of remappable key bindings. Check out https://code.visualstudio.com/docs/getstarted/keybindings to get started.
Again, Emacs is wonderful. I'm not going to try to talk anyone out of it. But I made myself use VS Code for a week and to adapt to its way of doing things, just as an experiment. By the end of the week, I was 90% as productive as with Emacs and I decided to stick it out. By the end of the second, I was more productive. It's just a really, really good fit for my own personal mental model of how code should be edited.
VSC looks and feels like a Mac app. Keyboard shortcuts to system services work the same there as in any other app. Emacs doesn't, however much time I spent trying to get it to do so. It also feels faster in a lot of ways because slow operations usually don't block UI updates.
VSC is way more popular lately, and it's extendable by people who don't want to learn elisp. I personally don't mind elisp at all, but I've come to accept that this is the minority position. So, what's that mean for VSC? It has a ludicrous number of packages / themes / etc., installable from the builtin package manager (that everyone actually uses; no more fetching code from some guy's website because he's politically opposed to the idea of a package manager), that actually work out of the box and are configurable through a GUI (or JSON if you want to commit the settings into source control).
I love Emacs, VSC is much better at editing Python than I've ever been able to configure Emacs to be. Linters and formatters are well supported and Just Work.
Here's the majority of my main settings.json file:
{
"files.trimTrailingWhitespace": true,
"[python]": {"editor.rulers": [99]},
"python.formatting.provider": "black",
"python.formatting.blackArgs": ["--line-length", "99"],
"python.linting.flake8Args": ["--max-line-length", "99"],
"workbench.colorTheme": "Dracula",
"editor.fontSize": 13,
"editor.fontWeight": "400",
"editor.fontFamily": "Fira Code",
"editor.fontLigatures": true,
"git.enableCommitSigning": true,
"workbench.iconTheme": "material-icon-theme",
"editor.formatOnSave": true
}
It's clearly not as configurable as init.el, but look how easy it is to change the theme or font size, and to add vertical rulers, and to configure font ligatures. As it turns out, I would much rather have settings be that simple than to have a Turing-complete language for computing the config at runtime. Others will disagree, and that's OK. But for me, it gets rid of one more massive excuse for screwing around with my editor config instead of writing code.