Maybe vscode has these built-in by now? Using the Gitless fork so not that annoying.
Yes, the blame feature is built-in now, with pop-up and all.
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".
Eventually someone will fork it just to remove the ads
I only used it for the automatic blame behind the cursor, but I just learned that that is built-in to VS Code (something like “toggle blame decorator”). The built-in one is faster too.
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.
Also what's your reasoning behind this?
It’s not quite emacs, but it scratches the itch
What are your reasons?
- Concentration of power/attention/market share/etc. can lead to abuse
- Competing ecosystems push each to get better
- Different tools can be good at solving different problems (e.g. different LLMs may be good as solving different tasks)
- Allows people to use tools they're more comfortable with (e.g. worked at one company where everyone was forced to use vim, needless to say I didn't want to stay there long)Magit IMNSHO is the absolute gold standard for git UIs (or "porcelains" as they used to be called back in the day). Nothing else even comes close.
(And a list of other Git related tools at https://github.com/magit/magit/wiki/Other-Tools.)
I’m almost locked into emacs because of magit lol
I find when I use vscode that most features have an emacs equivalent.
Am I missing out on something in that set of “stuff I don’t know I don’t know”?
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).
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.
What's great about Emacs that I don't have to restart or even save anything - I can enable/disable things on the go, even installing and using lsp-servers. I typically experiment in my scratch buffer (it's persistent between the sessions), and when my experiments prove worthy adding to the config, I move them.
I have VSCode and I run it sometimes, often when I'm working with someone who doesn't use Emacs. It almost invariably requires more attention and inflicts more annoyance. it-just-works™ rarely feels working for me there.
But, I’ll never find a replacement, I’m forever trapped ((((()))))) send help
Recently I've been trying jujutsu[0]. As awesome as Magit is, it can't fix some warts of Git like how it does conflict management. But I hate having to do version control from CLI. Most of all, I miss doing a bunch of work, going to magit-status (or edamagit), staging lines or entire files and committing parts of my work separately (like, dependency updates in a separate commit before committing api changes).
I've tried VisualJJ[1] and GG[2] but I just can't find a nice workflow with jj coming from Magit. Splitting changes feel cumbersome. What is your commit workflow with jj coming from Magit?
It always felt a little clunky, because it would randomly stop working. Regardless, it was a huge time and context-switch saver. I also tried binding `git commit` through the extension somehow, but I couldn't figure it out.
Emacs doesn't have "extensions", because every package can be used as a library or radically change the behavior not only Emacs itself but other packages too. Magit's parts been used in other packages - transient.el has evolved into a separate package; magit-section is used in packages like code-review.el, forge, notmuch; magit-git - low-level git interface functions used by packages like diff-hl, git-gutter, etc.; process handling abstraction used by packages that need async process management; etc.
VSCode extensions run in isolation, you can't directly call functions of one extension from another, you can only use what an extension explicitly exposes via its public API (if any). In comparison, Emacs users can freely incorporate Magit's internal commands into their configs, extend them and combine multiple packages seamlessly.
In Emacs, one could write a 5-line function that checks Magit's current branch, queries Projectile for project type, and then calls different Magit commands based on context. In VSCode, something like that would require formal APIs, message passing between extensions, and cooperation from all involved extension authors. In Emacs, you wouldn't even have to save the function on disk before trying it out.
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.
But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.
I sure do get the appeal of an out-of-the-box Emacs setup that does everything with modern defaults, but the base installation gets better, more ergonomic, and more powerful by the year on its own.
I have learned tons of things since then and on multiple occasions I thought about rebuilding things (with my now more extended knowledge) from scratch, but I'm afraid I will inevitably end up borrowing some core Doom macros, and end up recreating something that very much looks and feels like Doom, without being Doom, perhaps with a different package manager. That I believe is the only non-negotiable part of it today. Other than that, Doom is nothing but a very thin layer of abstraction. I don't even use Doom's own modules, instead I built the set of my own. Anyway, if you ever feel overwhelmed and decide to call another emacs.d bankruptcy, maybe give Doom a try. You can disable all the modules and build on top of that lean core, it still has objectively nice features - CLI tool is nice, macros like map! and add-hook! and defadvice! are very cool. It loads extremely fast, etc.
Doom may become obsolete only if it keeps partitioning into separate packages, e.g., doom-modeline started as a core component of Doom, now it's a separate package. Similarly, nothing really preventing anyone from forking other core parts of Doom into separate packages.
Also, evil-mode keys are optional, anyone can use Doom without using vim keys, there's still good value in doing that.
For example, in my current VSCode + GitLens setup (must admit that I have a corporate license for GitKraken, which enables full GitLens functionality). I use these features 99% of the time.
1. Convenient diff/merge with character-level diffs and visual indication of moved code.
2. A graphical commit tree with filtering, searching, numerous hovers with lots of information, and buttons to quickly jump to all sorts of diffs.
3. Interactive rebase (GUI for selecting those pick/squash/reword etc.)
4. Editing new and existing commit messages in vscode, which allows me to use better commit message formatters, LanguageTool and LLM extensions for rewriting/paraphrasing.
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.
Putting all Org-mode related features aside, since obviously Org-mode is much more Emacs-exclusive feature than Git support, here's what I see from your comments.
> If I want in my tab (there's tab-bar-mode in Emacs) some git-based info, I can easily do it.
I understand tab-bar is similar to tab bar in modern GUI editors - just a list of open files. Modern editors already mark dirty/staged files in the tab bar. Can you give an example of another information that one might want to add to each file?
> Like for example in Dired, where you'd be listing directories, you can mark some files and dirs, and stage those files
I assume Dired is some kind of file browser. While I appreciate the ability to integrate Magit with any file browser plugin, staging/unstaging files from the file tree sidebar is basic functionality of any editor with Git support. It's hard for me to imagine any life-changing improvement in this area.
> or show the git log pertaining only marked items.
Yes, that's neat. But IMO it's a very advanced feature that's used pretty rarely. Most of the time one wants to see either git log for current file or select some file in file tree in sidebar and see its log.
> Or I can hook into magit-post-commit-hook to trigger custom actions
You provided some examples for integration of Magit with note-taking. Advanced note-taking in emacs is a whole different world and I assume that person wanting to leave Emacs (but staying for Magit ;) will be ok with using some more mainstream note-taking software (like Obsidian etc.). So when using a code editor/IDE for its' original purpose - editing source code in some programming language, what would be a popular example of Magit hook that is not achievable with the existing Git hooks mechanism?
To clarify again my doubts, I think that someone who has mastered Elisp, maintains his own Emacs config and heavily customizes Emacs to his liking, would never consider moving to VScode or Jetbrains. However, all those Doom users evaluating to move to "mainstream" editors, who do only minor adjustments (like options, keybindings), do they get something substantial from Magit that they can't achieve in those editors?
Emacs can manage many different tasks — work as a web browser, email client, search agent, REST API tester, project manager, PDF reader, version-control tool, LLM frontend, chat app, and even text editor. Trying to evaluate it in any single function wouldn't be fair, because in isolation, any of these roles are imperfect - Emacs is most definitely not the best tool for any individual task. However, for me and many others, Emacs is first and foremost a "Lisp Machine" (technically you can't call it that, but that's semantics for a different conversation). When one truly grasps and appreciates this specific aspect, they can transform it into an incredibly versatile tool - it eventually does become the best web browser, email client, search agent, etc.
That's all philosophy, let me try to adress more concrete questions.
> imilar to tab bar in modern GUI editors - just a list of open files.
No, tab-bar in Emacs (just like many other things) is very extensible medium. You can use it to show almost anything you like. I use tabs for separating my project contexts. I can easily make it show project's git info, like current work-tree.
> I assume Dired is some kind of file browser.
It's not just a file browser, it's a "DiREctoryEDitor" — your file tree (including subdirs) is fully editable, you can use whatever features of your editor - macros, multiple cursors, search-n-replace, etc. You can change a bunch of filenames and apply your changes, they'll be reflected on the disk.
> it's a very advanced feature that's used pretty rarely.
That's just an example of simple integration of different packages. There are many different features like that, some of them you need to use just once to understand how powerful they are, even though rarely used.
> what would be a popular example of Magit hook that is not achievable with the existing Git hooks mechanism?
A popular example would be automatically updating buffer-local variables or Emacs-specific project settings when switching branches.
For instance, when switching from a "main" branch to a "feature/python-3.12" branch, a Magit hook could:
- Automatically switch your Python virtualenv/conda environment
- Update python-shell-interpreter to point to the correct Python version
- Adjust linting/formatting tools (switching between different ruff/flake8 configs)
- Change compile commands or test runners
While you could achieve some of this with Git hooks by writing shell scripts that modify files, Magit hooks can directly manipulate Emacs' internal state without the overhead of external processes or temporary files. They integrate seamlessly with Emacs' project.el, eglot/lsp-mode, and other development tools.
This is particularly valuable in polyglot projects where different branches might use different language versions or toolchains.
> do they get something substantial from Magit that they can't achieve in those editors?
For Doom users who only make minor adjustments like keybinds, Magit alone probably isn't a strong enough reason to stay on Emacs. As I mentioned earlier, focusing on just one aspect of Emacs is a misguided approach, which explains why these users eventually discover more specialized apps and abandon it. I regularly see comments like "I've used Emacs for nearly a decade, but still left..."
In a head-to-head (Git-focused) comparison, perhaps Magit is not going to win all the hearts. Besides, where Magit truly shines (interactive rebasing, selective staging, complex history manipulation) are features that power users love but casual and new users might rarely touch.
No one really gains anything substantial from Emacs after just a week or two of use. Emacs is a journey that sometimes takes years of simply persuading yourself to give it another try. Though I personally find it a worthwhile investment, I don't think adopting Emacs merely because "people say it has a killer Git interface" is the right approach. Everyone has different idea what makes a "killer Git interface," and Emacs might not provide what they're looking for — even though it undoubtedly has the potential to become the killer Git interface they seek.
yes, this is emacs poetry :)
What serious tool doesn't?
That right there is the problem. I have been an Emacs user for decades. Magit is awesome because of Emacs, not inspite of Emacs. Whatever this person is saying, either they have not given any real thought to their own experience, or they really don't care about anything other than Magit as a piece of software that they prefer using. If it's the latter, then only that person can tell you what is so great about Magit. But that line of thought is really hard to understand and counter for a typical developer who cares about their entire coding experience and not just any one package.
> However, all those Doom users evaluating to move to "mainstream" editors, who do only minor adjustments (like options, keybindings), do they get something substantial from Magit that they can't achieve in those editors?
No. I would be very skeptical of people who make such claims.
To see other editors or IDE having their own magit-inspired add-on and/or extension just shows how well designed magit is to get such worthy of respect.
I do appreciate VSCode provides support like this even for Magit. I would not be suprised if other text editors or IDEs support them as well like NeoVim or even JetBrains.
While the functionality is likely to meet the needs of many, I doubt it will come close to Magits functionality in emacs.
Emacs is so expressive. It not just magit.. is that magit has the power of emacs (and other bits in emacs has the power of magit)
I doubt VSCode provides this flexibility. Perhaps, for many, dont care or need it.
zkry•1d ago
Reference to the previously posted "You Can Choose Tools That Make You Happy"
> Emacs is a Gnostic cult. And you know what? That’s fine. In fact, it’s great. It makes you happy, what else is needed? You are allowed to use weird, obscure, inconvenient, obsolescent, undead things if it makes you happy.
Juxtaposing Emacs with the adjectives obsolescent, and undead is sad to read. Emacs is constantly reinventing and readapting itself, and just like Emacs takes and incorporates the best ideas from other tools, ideas from Emacs find their way to other environments.
squishington•1d ago
sureglymop•1d ago
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.
squishington•1d ago
eviks•1d ago
brendonjohn•1d ago
dhruvrajvanshi•1d ago
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.
eviks•1d ago
> it could but no one who uses Emacs is asking for it.
That would be impossible for no one to ask for better defaults over the course of so many years, and examples of such asks is a short search away. Besides you forgot the much bigger group of people who could be using emacs if it incorporated such best ideas as ergonomic UI...
> Mind that ergonomics is also very subjective.
Unless it's objective. As in, if your defaults lead to RSI on heavy use, they are objectively bad
> You might not find lisp very ergonomic, but Emacs users do.
So? The idea wasn't about banning lisp, but allowing other languages.
And before going with the other ways were half left from the original way
sham1•21h ago
There's nothing objective about that. All people can ever come up with when talking about RSI is a bunch of anecdata. Now, it's probably something to take into consideration, but that's by no means objective.
It's not like anyone has done a study about Emacs' key chords and their causal effect in repetitive stress injury, versus CUA bindings (which are actually available in Emacs, just not by default.)
At least my personal anecdote is that for me, the Emacs defaults are fine, and it seems to me that most problems people experience probably come from things like poor posture and crappy laptop keyboards, which would affect the ergonomics.
> > You might not find lisp very ergonomic, but Emacs users do. > > So? The idea wasn't about banning lisp, but allowing other languages.
That's just a small matter of programming. Of course, the real questions are "why?" and "is it worth it?"
Hell, with Guile Emacs being in somewhat active development again, that should help with getting more languages supported – although that's not the official goal of the effort – like JavaScript, which already has an experimental frontend in Guile mostly just bit rotting away since people aren't volunteering to help with it.
eviks•21h ago
> Of course, the real questions are "why?"
Are you having trouble answering such a simple question to feel the need to ask it?
But this is again missing the point, which was that there was no "reinvention incorporating the best ideas" because many surface-level good ideas aren't incorporated (same thing with the brighter future bit rotting plans...)
Koshkin•22h ago
turboponyy•20h ago
Vi is incredibly well-suited and ergonomic for text editing, and switching between the modes is efficient, since often times you want to begin typing text as a consequence of some other normal mode operation you'd want to take anyway - e.g. add line below; change until end of line; change in parens; change up to character - and those operations put you immediately into insert mode afterwards anyway.
So I wouldn't let that feature (which enables making common operations more ergonomic) stop you from using vi-style binds.
Though modelessness can be quite nice, and I do see the appeal. Being able to select a region and immediately perform any desired operation is convenient.
What's great is that Emacs is what you make it - you can mix and match the two approaches. I, for example, use vi binds for text editing in Emacs, but maintain modeless binds I can always access when it makes sense. You can have the best of both worlds :)
iLemming•19h ago
> What keeps me from using vi derivatives
That's correct. There's no such thing as "vim-mode". Every single Vim extension is full of glaring inconsistencies and shortcomings. Not a single VSCode extension, not IdeaVim for IntelliJ, not Sublime ones — none of them are really full-fledged vim integrations. Emacs one is the notable exception. Evil mode in fact is so good, it never feels like an afterthought, it feels like it was baked into the design of the editor from the get-go. It works extremely well. Emacs in fact can vim better than (Neo)vim.
chamomeal•1d ago
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
eviks•1d ago
christophilus•1d ago
throwanem•23h ago
iLemming•17h ago
Comprehending Emacs is a challenging journey that demands time, patience, and dedication. Yet why would anyone despise Emacs after spending time with it? It's like hating the mere existence of motorcycles after failing to learn how to ride one.
yoyohello13•20h ago
eviks•18h ago
jsilence•22h ago
[0] https://www.youtube.com/watch?v=wlR5gYd6um0