Wow, that definitely looks like a good magit replica in VSCode.

As someone who suggests every git user to try out magit (without all of the Emacs stuff that others dislike) because it provides a great mental model on how git works, this is very useful to people who use VSCode.

Some suggestions:

* Looks like the command UI is enabled through the VSCode command bar(? I'm not sure of the name) much alike Helm, but I think that the popup window style used in magit allows much more discoverability - a UI similar to that would be preferable.

* Just using the name magit inside the plugin name might not be the best naming; A rebranding would be better I think.

Here are some articles that explain how (the original) Magit is different from other Git clients:

* https://emacsair.me/2017/09/01/the-magical-git-interface

* https://emacsair.me/2017/09/01/magit-walk-through

What benefits does this bring over the built in vscode git commands?

Magit, together with maybe Org-mode, is one of the Emacs packages that make it very hard for people to migrate off Emacs, to other tools, ever.

Whatever IDE or editor I work in, I still use Emacs and Magit for Git interaction. Maybe that as perspective.

The biggest thing that I see as missing right off the bat is the popup. That lets you execute anything very fast. Having to use the Command Palette to run commands really breaks that flow.

The commands in the pallete can be triggered by a single key-press (indicated to the left of the item). This makes it only visually different from Magit.

Its not perfect, but close your eyes and its the same sequence of keys to triger an action.

Good start! Looks like it's still missing a lot of stuff I use daily, like staging chunks, ediff etc. I can actually imagine in 10 years that VSCode is going to be impossible to ignore even for die-hard Emacs users, so I do hope people keep iterating on this stuff, and Microsoft on the platform underneath it all.

The strength of emacs is that once you can program it it's extremely easy to write extensions for it, even for one off tasks, because it's so quick and easy.

Compared to this in vscode writing extensions is much more convoluted. You wouldn't create a new vscode extension for a 1 hour task, for example, while with emacs it's trivial to write some small code which can help you with your current task. I often do.

Is it that heavyweight? There’s nothing akin to just pasting something into your .emacs, or even a scratch buffer? I admit I have looked around with no luck.

Doesn’t seem like that’s improbable over the product’s lifetime though, if there’s enough demand.

I wished i knew how to do this.

That's amazing! After using Emacs for years, I switched to VS Code. Magit was one one of the things I really, _really_ missed from Emacs and I've never found anything remotely as nice. I'll definitely give this a try.

Tried vscode, but having to use the mouse for many operations put me off, raw text editing was also bad compared to emacs. To be fair this was for just two days trying to use vscode.

It's definitely a different paradigm. A couple of notes on keyboarding though:

- 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.

Why can't you run an Emacs with Magit alongside Vscode? You don't have to miss it, you can still use emacs for that.

This is like being on Android and having an IPhone just for some iOS-only app. It's brutal and flies in the face of all that is good and pure.

That's a pretty good analogy. Firing up Emacs for just one thing is a pretty large side dependency. Also, Emacs's keybindings are jarring when bouncing back and forth between apps custom built for a particular OS. They're not bad in any way, just very different.

It's like using an external tool for something if it's better than the internal implementation of the editor for the same thing.

Die hard emacs user here (but looking sometimes into vscode). Which things you get from vscode that couldn't get in emacs? Are you definitely set?

I've made the full switch. I still love Emacs, and if VS Code suddenly disappeared I'd switch right back. That said:

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.

Ability to run vscode in a browser

I’ve been using Magit inside a VSCode terminal for a couple weeks, this is a great alternative!

I tried magit briefly, but found it unusably slow. Is this different?