Edamagit: Magit for VSCode

> When I see comments like "Magit is the only thing that keeps me from leaving Emacs," I honestly wonder what they're going to miss.

The "killer feature" is how it makes git feel like a natural extension of text editing rather than a separate tool. Other git UIs exist, but none integrate the "edit-review-commit" cycle as seamlessly. It's less about any single feature and more about how it transforms git from something you "switch to" into something that's just... there.

A huge part of what makes Magit special - it's not just a UI, it's a complete git API for Emacs - Magit is a library, not only I can easily extend Magit's own functionality, I can just call its functions, advice them, etc.

For example: If I want in my tab (there's tab-bar-mode in Emacs) some git-based info, I can easily do it. Or I can hook into magit-post-commit-hook to trigger custom actions. This composability is impossible with standalone git clients. You're not just using a git interface - you're programming with git as a first-class citizen in your editor. Other tools give you a UI; Magit gives you building blocks.

There are integrations in Emacs that Magit author and maintainers never even thought about initially. Like for example in Dired, where you'd be listing directories, you can mark some files and dirs, and stage those files or show the git log pertaining only marked items.

But again, it's not so much about features that already exist in Magit, but the way how one can easily extend things to add features that are not there - and there are tons of examples - note-taking workflows (where using Org-roam/Denote one can stage specific thoughts from their daily notes, creating atomic commits of ideas); literate devops (where you keep tf/ansible scripts in Org-mode src blocks and commit directly from the same document); academic writing (e.g., with LLM integration); time tracking (where people hook to magit-post-comit to automatically log time entries); config management (where you use magit's cherry-pick to selectively sync specific configs between work/personal machines), etc., etc.

I have tried explaining magit to my fellow developers. And they kept showing me how they do similar things in their favourite IDE. Turns out that Magit in itself is not compelling. You have to first appreciate Emacs, and then you notice how perfectly well Magit "raises" git to the Emacs abstractions. I love Magit and rarely use the git commandline. But that's because Emacs fits my brain perfectly; the way Emacs deals with "things" (pun intended) is exactly how my brain works. And then Magit just makes version control feel like Emacs front and center.

Emacs is paradoxical — it always works, yet at the same time, any parts of your config may prove to be broken at any given moment. Maintaining a complex Emacs config is a chore. And not because of Emacs itself, core of Emacs is remarkably stable, most issues are in the customization layer you control.

What you get in return though is far more valuable than any alternative — when something breaks, YOU can fix it. You're not waiting for a vendor or update. The system is transparent and malleable. Each fix teaches you something. Over time, you build deep understanding of your environment. The chores become easier. Unlike rigid software, Emacs molds to your exact workflow. The maintenance cost pays for a tool that works EXACTLY how you think.

Emacs is a professional chef's kitchen - A chef maintains their knives, adjusts recipes, deals with temperamental ovens. More work than a microwave dinner, but they can create ANYTHING. When the soufflé fails, they know why and can fix it.

"Yeah, well", some may say, "I don't want to be a chef, I just want to occasionally fix some bad cookies, using the 'easy-cookie-maker-kit', it just-works™, why not use it?".

I can tell you my perspective on that. I decided to "become a chef" and use "my own kitchen", because I'm tired of different types of cookie-maker-kits. It seems like everyone has a different opinion of what the cookie-maker-kit should look like, what it should do, what kind of cookies can you make with it. Every few years, the "ultimate" kit appears, promises to revolutionize cookie-making, then gets abandoned or dramatically changed. Your muscle memory becomes worthless. Your recipes need rewriting. The new kit can't make the cookies you loved.

But in my kitchen? My grandmother's rolling pin still works. The oven I learned five years ago still bakes the same way. When I discover a new technique, I add it to MY repertoire, not wait for someone to maybe include it in Cookie-Maker-Kit 3.0. Sure, I burned a few batches learning temperature control. Yes, I maintain my tools. But now I can make cookies, and bread, and soufflés, and things that don't even have names yet.

The cookie-kit users are still arguing about whether round or square cookies are "correct," while I'm over here making star-shaped ones because I felt like it today.

The shortcuts are kind of a big deal though. Im writing transient modes for everything I can. Its the perfect UI for git but also other productivity tasks. For example I wrapped our issue tracker (youtrack) in a transient mode and it has made it so much more enjoyable to use.

I just found it - it's "Git > Blame > Editor Decoration: Enabled" and holy is it so much faster. I love every time I can replace an extension with native functionality.

Interesting. I've been using Gitlens for years without issue. Today I tried the built-in blame decorations and I found they were so responsive and fast that they were distracting. With Gitlens there's a delay before the decoration appears on a line, so if you're moving your cursor quickly around between lines you don't actually get a blame decoration until you've rested there for a few seconds; with the built-in functionality it pops right up as soon as the line focuses so if you go from line to line, there's a lot of activity in your field of view which makes it harder for me to concentrate on the code.

As an adjustment, for now, I'm sticking with the built-in functionality but enabling only the status bar display, whose template I modified to include the commit message and date.

TIL blame is builtin in VS Code, thanks for sharing, I had GitLens just for the blame, never used another feature.

The “compare references” feature is nice.

Gitless is this fork https://marketplace.visualstudio.com/items?itemName=maattdd.... it's not updated but still works well.

Probably just got used to it. It was IMO very good plugin 5 years ago or so before all the ads etc.

A lot of it was first-mover advantage. It was the first VS Code plugin to provide a lot of the in-place information that it did, and at first it was unobtrusive and just did the one job well. It only started becoming truly annoying when it became a GitKraken product designed to sell more GitKraken products.

Now that VS Code has more of those features built in and there are alternatives the first mover advantage keeps the extension sticky because people don't feel pressure to learn about the built-in features or because people don't want to learn about alternative extensions because "the tool I already know is annoying but is fine".

It makes selectively stash/peeking/applying etc easier. Their flagship feature, the hover popup to reveal original commit/PR that you can click on is usefe for investigation.

Maybe vscode has these built-in by now? Using the Gitless fork so not that annoying.

This is beautiful, thank you!

I can confirm that pretty much anything that can be done in VSCode can be done in Emacs from my seven yeas of experience. I guess the only hurdle would be having to spend some time to configure some things, though for the most part installing packages in Emacs is very hassle free. A lot of companies, probably to promote their product, will create VSCode extensions. These never seem to be absolutely necessary.

To me the biggest thing would be company politics. There's some companies that have a policy to use a certain editor (to share config and whatnot).

Absolutely nothing for most! I just really dread lisp and extending my editor shouldn’t feel so dreadful.

But, I’ll never find a replacement, I’m forever trapped ((((()))))) send help

I prefer to use emacs but it just doesn't fit well for the kinds of work I do the last few years. I am often switching between very different projects, usually for a short period to accomplish a specific goal. The per language (and per version, and per framework etc) config is just too much when I'm likely only going to be working in a specific codebase for a few weeks or even days.

VS code (or whatever jetbrains thing) works well enough with almost no config where emacs works better with a lot more config. Worth it for some kinds of work but not others.

I find it interesting because they probably unknowingly could already control emacs quite well. The gnu readline key bindings are pretty much the same as the emacs ones and are universally used in text editing environments and REPLs. For example in html text inputs or in all text editing contexts on macOS.

They were the first thing I missed when first trying out insert mode in vim. I also think the concept of major and minor modes is overall simpler and easier to understand than how this works in e.g. neovim.

However I still prefer neovim because I believe lua to be overall nicer to use. Nothing against lisp and I understand it is incredibly simple and powerful. But I feel most people just want to have an easy way to configure their editor and imo the developer ergonomics for lua are better. Especially also with formatting, typing and other tooling. Nested lua tables look almost exactly like json, while the same structure in elisp would probably confuse someone switching over from vs code.

> Has emacs reinvented itself to incorporate the best ideas of being very performant, allowing better languages for extensions, replacing health-hazardous default keybinds with something ergonomic, using commonly understood terms for its interface?

Yes! It's called Evil mode. It emulates vim keybindings.

In terms of "normal" keyboard shortcuts, it could but no one who uses Emacs is asking for it. Mind that ergonomics is also very subjective. You might not find lisp very ergonomic, but Emacs users do. They find other languages unergonomic.

Other ways Emacs has borrowed ideas from other editors.

It now has first party tree sitter integration for better syntax highlighting. I believe this was borrowed from the neovim world.

It has plugins for LSP...borrowed straight from the VSCode world.

If it matters, I've never used Emacs in my life, so I'm not a part of their weird cult. But i can see that they do things the way they do for a reason. They're not a bunch of morons.

Emacs is a truly Free software project, one of the last. It's meant to be molded however the user wants. Nobody gives a shit if you use Emacs. If you don't like it for some reason then please leave us alone and feel free to return to the corporate captured hellscape that is VSCode.

Yep lots of modern (even IDE-like) flavors of emacs like that. Doom emacs (which includes vi key bindings and modes), spacemacs, etc.

I’ll also say for “commonly understood terms”: discoverability in emacs is amazing. You have dedicated commands just for checking what other commands do, searching docs, finding keybinds for existing commands or vice versa. It’s SO sick!!

Vscode is great too, for very different reasons

Yes

> I think it's always a good thing to have a polyculture of dev tools.

What are your reasons?