7 ms·

There's no such thing as "Magit for VSCode", it could be "Magit-like" or "Magit inspired", but never can replace Magit, simply because Magit is not an extension

There's no such thing as "Magit for VSCode", it could be "Magit-like" or "Magit inspired", but never can replace Magit, simply because Magit is not an extension, it's an Emacs package. 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.

cmrdporcupine 1y ago
All of this is true. And it's also why inevitably all my more complicated emacs configurations inevitably end up broken in some way over time :-)
- iLemming 1y ago
  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.
  - reddit_clone 1y ago
    >Maintaining a complex Emacs config is a chore. I have given up and adopted Doom Emacs. Let cleverer people do the wrangling
    - cmrdporcupine 1y ago
      I feel like Doom is maybe obsolescent on account of standard out of the box emacs having fairly easy to set up these days, with themes and LSP and etc just there out of the box and package-install just working. But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.
      - kstrauser 1y ago
        That's also why I don't use it. It's not bad at all! It's just not how I want to use Emacs. It's not right for me. 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.
        iLemming 1y ago
        "out-of-the-box Emacs setup" was never a thing that lured me into trying it. I liked the idea of modularity with Doom. Before that I never knew where to put things, how to split them, how to make them work with one another, how to disable features without breaking some others. 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.
qyron 1y ago
Seeing all the praise for Magit in these and numerous other threads, could someone please elaborate on its standout features that are missing from other editors/IDEs (VSCode+extensions or JetBrains)? 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.
- iLemming 1y ago
  > 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.

cmrdporcupine 1y ago

All of this is true. And it's also why inevitably all my more complicated emacs configurations inevitably end up broken in some way over time :-)

iLemming 1y ago
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.
- reddit_clone 1y ago
  >Maintaining a complex Emacs config is a chore. I have given up and adopted Doom Emacs. Let cleverer people do the wrangling
  - cmrdporcupine 1y ago
    I feel like Doom is maybe obsolescent on account of standard out of the box emacs having fairly easy to set up these days, with themes and LSP and etc just there out of the box and package-install just working. But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.
    - kstrauser 1y ago
      That's also why I don't use it. It's not bad at all! It's just not how I want to use Emacs. It's not right for me. 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.
      - iLemming 1y ago
        "out-of-the-box Emacs setup" was never a thing that lured me into trying it. I liked the idea of modularity with Doom. Before that I never knew where to put things, how to split them, how to make them work with one another, how to disable features without breaking some others. 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.

qyron 1y ago

Seeing all the praise for Magit in these and numerous other threads, could someone please elaborate on its standout features that are missing from other editors/IDEs (VSCode+extensions or JetBrains)? 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.

iLemming 1y ago
> 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.