8 ms·

Edamagit: Magit for VSCode

128 points by tosh 1y ago

zkry 1y ago
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.
- squishington 1y ago
  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.
  - sureglymop 1y ago
    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.
    - squishington 1y ago
      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.
- eviks 1y ago
  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?
  - brendonjohn 1y ago
    Yes
  - dhruvrajvanshi 1y ago
    > 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.
    - eviks 1y ago
      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
- jsilence 1y ago
  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 https://www.youtube.com/watch?v=wlR5gYd6um0
tempodox 1y ago
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.
- anonzzzies 1y ago
  Yep. Gitlens is a very annoying thing. Not sure why people put up with it.
  - budding2141 1y ago
    Probably just got used to it. It was IMO very good plugin 5 years ago or so before all the ads etc.
  - nsonha 1y ago
    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.
    - RaoulP 1y ago
      > Maybe vscode has these built-in by now? Yes, the blame feature is built-in now, with pop-up and all.
      - pinoy420 1y ago
        [dead]
  - WorldMaker 1y ago
    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".
anonzzzies 1y ago
I'll definitely try it even though i'm weening of vscode in favour of emacs again. But my colleagues are not.
- algo_lover 1y ago
  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?
  - anonzzzies 1y ago
    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.
- chamomeal 1y ago
  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
- uludag 1y ago
  The Emacs ecosystem has never been better! I think it's always a good thing to have a polyculture of dev tools.
  - ksajh 1y ago
    > I think it's always a good thing to have a polyculture of dev tools. What are your reasons?
    - uludag 1y ago
      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)
kunzhi 1y ago
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.
tarsius 1y ago
I've collected a list of projects that are inspired by Magit at https://github.com/magit/magit/wiki/Inspired-by-Magit 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 https://github.com/magit/magit/wiki/Other-Tools.)
- tretiy3 1y ago
  Hey! Is it ok to add one more stand-alone client to that page?
- caladin 1y ago
  Thank you for creating and continuing to work on Magit!
deleted 1y ago
[deleted]
kombine 1y ago
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.
- tcoff91 1y ago
  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.
costrouc 1y ago
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.
Robdel12 1y ago
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
- norman784 1y ago
  There is a TUI called gitu[0], not sure how close is to magit in terms of features. [0] https://github.com/altsem/gitu https://github.com/altsem/gitu
  - Robdel12 1y ago
    This is beautiful, thank you!
- lyall 1y ago
  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.
- eulers_secret 1y ago
  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”?
  - Robdel12 1y ago
    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
  - uludag 1y ago
    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).
mcc1ane 1y ago
GitSavvy for Sublime Text is comparable, if not better.
osener 1y ago
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 https://github.com/jj-vcs/jj [1] https://www.visualjj.com/ https://www.visualjj.com/ [2] https://github.com/gulbanana/gg https://github.com/gulbanana/gg
- 90s_dev 1y ago
  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.
  - johanvts 1y ago
    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.
    - iLemming 1y ago
      Yeah, Transient is very nice. Watch my vid for some good ideas https://news.ycombinator.com/item?id=44025635 https://news.ycombinator.com/item?id=44025635 (unrelated to Magit)
iib 1y ago
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.
iLemming 1y ago
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.
tretiy3 1y ago
Looks good! Shameless plug: i am building my own standalone linux only version https://github.com/aganzha/stage https://github.com/aganzha/stage
masfoobar 1y ago
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.

128 points by tosh 1y ago

zkry 1y ago

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.

squishington 1y ago
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.
- sureglymop 1y ago
  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.
  - squishington 1y ago
    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.
eviks 1y ago
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?
- brendonjohn 1y ago
  Yes
- dhruvrajvanshi 1y ago
  > 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.
  - eviks 1y ago
    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
jsilence 1y ago
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 https://www.youtube.com/watch?v=wlR5gYd6um0

tempodox 1y ago

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.

anonzzzies 1y ago
Yep. Gitlens is a very annoying thing. Not sure why people put up with it.
- budding2141 1y ago
  Probably just got used to it. It was IMO very good plugin 5 years ago or so before all the ads etc.
- nsonha 1y ago
  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.
  - RaoulP 1y ago
    > Maybe vscode has these built-in by now? Yes, the blame feature is built-in now, with pop-up and all.
    - pinoy420 1y ago
      [dead]
- WorldMaker 1y ago
  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".

anonzzzies 1y ago

I'll definitely try it even though i'm weening of vscode in favour of emacs again. But my colleagues are not.

algo_lover 1y ago
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?
- anonzzzies 1y ago
  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.
chamomeal 1y ago
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
uludag 1y ago
The Emacs ecosystem has never been better! I think it's always a good thing to have a polyculture of dev tools.
- ksajh 1y ago
  > I think it's always a good thing to have a polyculture of dev tools. What are your reasons?
  - uludag 1y ago
    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)

kunzhi 1y ago

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.

tarsius 1y ago

I've collected a list of projects that are inspired by Magit at https://github.com/magit/magit/wiki/Inspired-by-Magit 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 https://github.com/magit/magit/wiki/Other-Tools.)

tretiy3 1y ago
Hey! Is it ok to add one more stand-alone client to that page?
caladin 1y ago
Thank you for creating and continuing to work on Magit!

deleted 1y ago

[deleted]

kombine 1y ago

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.

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

costrouc 1y ago

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.

Robdel12 1y ago

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

norman784 1y ago
There is a TUI called gitu[0], not sure how close is to magit in terms of features. [0] https://github.com/altsem/gitu https://github.com/altsem/gitu
- Robdel12 1y ago
  This is beautiful, thank you!
lyall 1y ago
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.
eulers_secret 1y ago
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”?
- Robdel12 1y ago
  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
- uludag 1y ago
  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).

mcc1ane 1y ago

GitSavvy for Sublime Text is comparable, if not better.

osener 1y ago

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 https://github.com/jj-vcs/jj [1] https://www.visualjj.com/ https://www.visualjj.com/ [2] https://github.com/gulbanana/gg https://github.com/gulbanana/gg

90s_dev 1y ago
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.
- johanvts 1y ago
  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.
  - iLemming 1y ago
    Yeah, Transient is very nice. Watch my vid for some good ideas https://news.ycombinator.com/item?id=44025635 https://news.ycombinator.com/item?id=44025635 (unrelated to Magit)

iib 1y ago

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.

iLemming 1y ago

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.

tretiy3 1y ago

Looks good! Shameless plug: i am building my own standalone linux only version https://github.com/aganzha/stage https://github.com/aganzha/stage

masfoobar 1y ago

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.