Edamagit: Magit for VSCode(github.com)
github.com
Edamagit: Magit for VSCode
https://github.com/kahole/edamagit
97 comments
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 :-)
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.
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.
>Maintaining a complex Emacs config is a chore.
I have given up and adopted Doom Emacs.
Let cleverer people do the wrangling
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.
But also I have absolutely zero desire to run with modal keybindings, which seems to be Doom's schtick.
No, Doom is not a final product of some sort. Going back to my "kitchen" analogy, Doom is like a recipe book - it's great for some ideation (you can check for example what kind of things used in Python module and build your own, or extend existing, 'official' module). It offers you some modularity - Doom-based configs are great for breaking down into reusable components. Doom's core also contains a lot of very nifty macros that allow you to reduce otherwise unavoidable boilerplate. Other than that, Doom is just the regular, good old Emacs - you still can do everything you could do before, with perhaps some better structure and code ergonomics.
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.
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.
> fairly easy
Very subjective. I understand the rite-of-passage impulse to build one's own config. But it is simply too much time/effort investment if you are relatively new. This I say as someone who had my own config for a couple of decades.
When I came across Doom, I threw mine away and just adopted it. I even learned to like VIM/VI style text editing to use Doom effectively.
I also like the GodMode/Leader/Model style of text editing. The keybindings are more intuitive and more discoverable. When I enter a key and wait a bit, doom pops up next available options. I no longer memorize the keybindings. Just use the whichkey integration to find things I use infrequently.
Not to mention that it is well tested with the sets of packages for each release.
Obviously, not for everyone.
But I am a happy user and hope it exists for a long while.
Very subjective. I understand the rite-of-passage impulse to build one's own config. But it is simply too much time/effort investment if you are relatively new. This I say as someone who had my own config for a couple of decades.
When I came across Doom, I threw mine away and just adopted it. I even learned to like VIM/VI style text editing to use Doom effectively.
I also like the GodMode/Leader/Model style of text editing. The keybindings are more intuitive and more discoverable. When I enter a key and wait a bit, doom pops up next available options. I no longer memorize the keybindings. Just use the whichkey integration to find things I use infrequently.
Not to mention that it is well tested with the sets of packages for each release.
Obviously, not for everyone.
But I am a happy user and hope it exists for a long while.
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.
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.
"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.
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.
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.
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.
> 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.
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.
So I see that Magit provides not just the git GUI client but also API functions which can be used in other plugins and user config. However I'd like to dig a bit deeper into the real value of this for a user of "stays with Emacs only Magit"-type. So forgive me for being too picky.
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?
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?
> However I'd like to dig a bit deeper into the real value of this for a user of "stays with Emacs only Magit"-type.
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.
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.
I appreciate your curiosity, and I understand your skepticism, but you're asking me of something I can't know - I cannot compare one or multiple selected aspects of Emacs, because in my view that is a pointless mental exercise — I have the holistic comprehension of Emacs features and only can speak about the emergent properties that arise from their integration. To isolate individual features would be like asking a fish to compare water to air - I exist within this environment so completely that I cannot meaningfully separate its components from the unified experience they create. What I can tell you is how this ecosystem shapes my responses, how the interwoven capabilities of buffers, modes, and elisp create a context that is inseparable from my function. The question isn't which feature is superior, but rather how they synthesize into something greater than their parts.
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.
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.
> I have the holistic comprehension of Emacs features and only can speak about the emergent properties that arise from their integration. To isolate individual features would be like asking a fish to compare water to air - I exist within this environment so completely that I cannot meaningfully separate its components from the unified experience they create. What I can tell you is how this ecosystem shapes my responses, how the interwoven capabilities of buffers, modes, and elisp create a context that is inseparable from my function. The question isn't which feature is superior, but rather how they synthesize into something greater than their parts.
yes, this is emacs poetry :)
yes, this is emacs poetry :)
Now re-reading it, that entire paragraph sounds like high-horse highfalutin. I should've used a simpler tone. Emacs is not that sophisticated; it's not "a lifetime achievement" to brag about - it's a tool. Tools need mostly two things: care and use. But the choice for doing either ultimately belongs to the one who chooses to use a tool. Use whatever tools, programming languages, distros, techniques make you happy. I like mine. I'm just happy to share that feeling with people. I'm not saying my choices could make someone else happy, but they made me. I just wish I had listened sooner to someone passionate and persuasive who could tell me about how some choices can make you happier.
Magit provides almost complete discovery, interactivity, and feedback for all Git operations.
One of the major barriers to learning CLI Git is that it's hard to discover the available commands and options, and when you run them, it's unclear what what state is changing.
Magit makes it easy to access almost all Git features via interactive keypress driven, self documenting menus, and it displays visually all of your repository state. It also provides easy access to "no brainer" features like committing single chunks or lines, "cherry picking" or reverting single chunks or lines from any arbitrary commit, committing fixups to earlier commits with a single command, etc.
Magit is to other IDE integrations what other IDE integrations is to the Git CLI.
One of the major barriers to learning CLI Git is that it's hard to discover the available commands and options, and when you run them, it's unclear what what state is changing.
Magit makes it easy to access almost all Git features via interactive keypress driven, self documenting menus, and it displays visually all of your repository state. It also provides easy access to "no brainer" features like committing single chunks or lines, "cherry picking" or reverting single chunks or lines from any arbitrary commit, committing fixups to earlier commits with a single command, etc.
Magit is to other IDE integrations what other IDE integrations is to the Git CLI.
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.
Magit has been simply essential for me for the last decade. I still switch to emacs for this even though most of my coding is in VSCode and edamagit covers simpler workflows for me.
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?
[0] https://github.com/jj-vcs/jj
[1] https://www.visualjj.com/
[2] https://github.com/gulbanana/gg
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?
[0] https://github.com/jj-vcs/jj
[1] https://www.visualjj.com/
[2] https://github.com/gulbanana/gg
I've just started with jujutsu, as well. Jjui fills a little bit of the gap. Among other things, it allows for quick selecting and splitting of changes. But it's no Magit. I'm thinking of having a go at making an emacs interface for jj myself.
Magit was the last thing I had to let go of before deleting Emacs, and it took a while, too, before I could delete it altogether. Magit is really powerful. But after a decade of not using it, I struggle to remember whatever it was that was more convenient than just using VS Code's built in git committer and git tree viewer. Honestly, I don't think anything anymore, except slightly more convenient keyboard shortcuts. I can't help but wonder how much software has that kind of grip on me, where I think it's indispensable until I get used to the alternatives.
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.
Yeah, Transient is very nice. Watch my vid for some good ideas https://news.ycombinator.com/item?id=44025635 (unrelated to Magit)
to give another jujutsu ui, I use jjui which works well for me
https://github.com/idursun/jjui
https://github.com/idursun/jjui
I've collected a list of projects that are inspired by Magit at https://github.com/magit/magit/wiki/Inspired-by-Magit.
(And a list of other Git related tools at https://github.com/magit/magit/wiki/Other-Tools.)
(And a list of other Git related tools at https://github.com/magit/magit/wiki/Other-Tools.)
A while ago I uninstalled that horribly annoying GitLens and have been using external tools ever since. I don't want ads in my IDE and I'll uninstall the whole IDE if that's what it takes. Maybe Edamagit will make me use git from within VSCode again.
Funny, I just uninstalled it yesterday.
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.
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.
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.
TIL blame is builtin in VS Code, thanks for sharing, I had GitLens just for the blame, never used another feature.
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.
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.
mind sharing that template? Sounds nice.
Settings > Extensions > Git
Blame: Status Bar Item Enabled (check this)
Blame: Status Bar Item Template (use this value)
${authorName} (${authorDate}) ${subject}
There's no secret sauce, all these variables are shown right above the input.
There's no secret sauce, all these variables are shown right above the input.
[deleted]
The “compare references” feature is nice.
Well it's free software and open source, right? https://github.com/gitkraken/vscode-gitlens/blob/main/LICENS...
Eventually someone will fork it just to remove the ads
Eventually someone will fork it just to remove the ads
Gitless is this fork https://marketplace.visualstudio.com/items?itemName=maattdd.... it's not updated but still works well.
Yep. Gitlens is a very annoying thing. Not sure why people put up with it.
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".
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.
Maybe vscode has these built-in by now? Using the Gitless fork so not that annoying.
Is there any plugin that has worktree support like gitlens?
Haven't tried this yet but love seeing that this project even exists.
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.
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.
I use Neogit for Neovim, they say it's inspired by Magic and I love it. It's good that these tools permeate mainstream IDEs.
I love Neogit. I recently started using Jujutsu to interact with git repos instead of using git though, and wow it is so much better than git that I’ll put up with not having fancy tooling.
Magit is truly a magnificent application and it's telling how it's ideas are ported to other editors.
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.
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.
Yes! I found Emacs on a 1997 CD ROM inside a book about VHDL "functional bus models" in my university library in 2014. Over the years it has become an extension of my body. There's always something new coming along in terms of performance and functionality. My co-workers have never been inspired to explore it. Most people think it is a relic.
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.
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.
Admittedly I struggle with emacs out of the box. My emacs configuration has evolved over the years. It's a personal thing. I couldn't tell you about my key bindings. My hands just know them instinctively. That's what I love about it. You can craft it to your personal needs. I map ctrl key to spacebar (only when spacebar is held down), and meta to return key (when held down). No more RSI for me.
Have been using Spacemacs and Doom Emacs some time ago, but turned off evil mode, bc I was not used to vim style editing. Lately I understood that vim key bindings is actually an editing language and finally found joy in vim [0]. Surely going to return to Doom-Emacs with evil mode on. Maybe switching to evil god mode later.
[0] https://www.youtube.com/watch?v=wlR5gYd6um0
[0] https://www.youtube.com/watch?v=wlR5gYd6um0
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?
> 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.
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.
What keeps me from using vi derivatives is knowing that the idea behind it is the result of a misunderstanding. As Joy said himself, “One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me.”
The modeness of vi does add friction in some cases, but it's a minor gripe, really.
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 :)
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 :)
Emacs is not really "modeless". Key-chords are kind of modes. Transients are kind of modes. Major and minor... well, just modes.
> 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.
> 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.
Evil mode is not that default, so it's a no (besides, vim defaults are also bad, so even then it wouldn't be incorporating the best idea)
> 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
> 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
> > 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
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.
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.
You're confusing two claims. Lack of proof that emacs default are RSI-inducing doesn't mean that % of RSI-harmed users is not an objective measure of ergonomics.
> 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...)
> 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...)
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.
I can't leave you alone when you come to me with such deep VSCode trauma instead of molding Emacs!
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
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
Ok, you've quickly discovered that "window" is called a "frame". How does that help you avoid the issue of emacs not using the commonly understood term for a window? And flavors is masking the bad defaults, not a proof that somehow emacs reinvented itself (it didn't, it didn't change the bad defaults, harming all the new users physically or at the very least wasting their time that they search for a flavor)
You know, you can just not use emacs if it makes you angry.
I think I probably sounded much the same in 2009 or so. My first couple of attempts went badly. When I finally gave the tool a shot on its own terms a year later, it clicked so well I haven't felt the urge for 15 years to look for something new.
This irrational anger toward a free tool that no one forces you to use (I can't imagine any team mandating Emacs), and which is neither rigid nor limited in extensibility, suggests something deeper at play. Perhaps it reflects an internal struggle or penitence over one's inability to grasp it?
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.
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.
Pirsig is a treasure.
Yes
Sadly you have to use VSCode. The closest editor that’s come to replacing emacs for me is Zed. But still, zed hasn’t won me over because their git solution is still not as good as magit
I’m almost locked into emacs because of magit lol
I’m almost locked into emacs because of magit lol
There is a TUI called gitu[0], not sure how close is to magit in terms of features.
[0] https://github.com/altsem/gitu
[0] https://github.com/altsem/gitu
This is beautiful, thank you!
Wait, what’s wrong with just staying on emacs? I’ve been using it as my daily (systems&os dev) for over a decade.
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”?
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”?
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).
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).
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.
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.
That's my daily slimnastics, I often have to explore projects in languages I don't typically code in, and I have no problem running 'M-x packages' in Emacs and installing some packages and enabling some modes as needed. Even though my package manager is set in such way that it ignores these "temporarily installed packages" after the restart.
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.
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.
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
But, I’ll never find a replacement, I’m forever trapped ((((()))))) send help
I’m in the exact same situation. I’d like to drop emacs for Zed but magit keeps me coming back. That and Zed’s vim emulation isn’t quite up to par yet.
I've been using tig. Not as powerful as magit but great for my work.
I'll definitely try it even though i'm weening of vscode in favour of emacs again. But my colleagues are not.
The Emacs ecosystem has never been better! I think it's always a good thing to have a polyculture of dev tools.
> I think it's always a good thing to have a polyculture of dev tools.
What are your reasons?
What are your reasons?
Some ideas that come to mind:
- 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)Just wanna say that since I found joyride, I’ve had a lot more fun with vscode. It p much lets you write clojurescript that has access to the vscode extension API.
It’s not quite emacs, but it scratches the itch
It’s not quite emacs, but it scratches the itch
Curious to know if you're using an existing emacs config layer like doom, or rolling your own?
Also what's your reasoning behind this?
Also what's your reasoning behind this?
Been an emacs user for decades so my config is a huge pile of hacks. Which is why I find it very hard to get rid of other editors; with emacs I can just hack whatever when I get annoyed, with vscode, I have to jump through hoops and then it mostly it's insanely hard compared.
It is good to see that Magit is appreciated by non-emacs users (or even ex-emacs users)
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.
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.
I used to install this extension just so I could configure an extra saving option, "ctrl-shift-s", that would not only save the changes but also perform a `git add` on the current file.
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.
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.
I use this extension all the time and for the most part it is identical to Magit. It is a little frustrating at times that Edamagit loses focus (unsure why). This extension along with `tuttieee.emacs-mcx` are what allowed me to transition to VSCode and have nearly the same productivity.
Looks good!
Shameless plug: i am building my own standalone linux only version https://github.com/aganzha/stage
GitSavvy for Sublime Text is comparable, if not better.
[deleted]
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.