[HN Gopher] Edamagit: Magit for VSCode
___________________________________________________________________
Edamagit: Magit for VSCode
Author : tosh
Score : 118 points
Date : 2025-05-29 07:58 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| zkry wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yes
| dhruvrajvanshi wrote:
| > 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 wrote:
| 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
| sham1 wrote:
| > > 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.
| eviks wrote:
| 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...)
| Koshkin wrote:
| 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."
| turboponyy wrote:
| 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 :)
| iLemming wrote:
| 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.
| chamomeal wrote:
| 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
| eviks wrote:
| 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)
| christophilus wrote:
| You know, you can just not use emacs if it makes you
| angry.
| throwanem wrote:
| 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.
| iLemming wrote:
| 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.
| yoyohello13 wrote:
| 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.
| eviks wrote:
| I can't leave you alone when you come to me with such deep
| VSCode trauma instead of molding Emacs!
| jsilence wrote:
| 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
| tempodox wrote:
| 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 wrote:
| Yep. Gitlens is a very annoying thing. Not sure why people put
| up with it.
| budding2141 wrote:
| Probably just got used to it. It was IMO very good plugin 5
| years ago or so before all the ads etc.
| nsonha wrote:
| 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 wrote:
| > Maybe vscode has these built-in by now?
|
| Yes, the blame feature is built-in now, with pop-up and
| all.
| WorldMaker wrote:
| 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".
| nextaccountic wrote:
| 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
| artemisart wrote:
| Gitless is this fork https://marketplace.visualstudio.com/ite
| ms?itemName=maattdd.... it's not updated but still works
| well.
| RaoulP wrote:
| 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.
| norman784 wrote:
| TIL blame is builtin in VS Code, thanks for sharing, I had
| GitLens just for the blame, never used another feature.
| SketchySeaBeast wrote:
| 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.
| lbussell wrote:
| The "compare references" feature is nice.
| oldandboring wrote:
| 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.
| cschneid wrote:
| mind sharing that template? Sounds nice.
| Iwan-Zotow wrote:
| second to ask to share
| baxuz wrote:
| Is there any plugin that has worktree support like gitlens?
| anonzzzies wrote:
| I'll definitely try it even though i'm weening of vscode in
| favour of emacs again. But my colleagues are not.
| algo_lover wrote:
| 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?
| chamomeal wrote:
| 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 wrote:
| The Emacs ecosystem has never been better! I think it's always
| a good thing to have a polyculture of dev tools.
| ksajh wrote:
| > I think it's always a good thing to have a polyculture of
| dev tools.
|
| What are your reasons?
| uludag wrote:
| 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 wrote:
| 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 wrote:
| 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.)
| tretiy3 wrote:
| Hey! Is it ok to add one more stand-alone client to that page?
| kombine wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| There is a TUI called gitu[0], not sure how close is to magit
| in terms of features.
|
| [0] https://github.com/altsem/gitu
| Robdel12 wrote:
| This is beautiful, thank you!
| lyall wrote:
| 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 wrote:
| 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"?
| uludag wrote:
| 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).
| giraffe_lady wrote:
| 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.
| iLemming wrote:
| 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(tm) rarely feels working for me
| there.
| Robdel12 wrote:
| 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
| myaccountonhn wrote:
| I've been using tig. Not as powerful as magit but great for my
| work.
| mcc1ane wrote:
| GitSavvy for Sublime Text is comparable, if not better.
| osener wrote:
| 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
| 90s_dev wrote:
| 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 wrote:
| 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 wrote:
| Yeah, Transient is very nice. Watch my vid for some good
| ideas https://news.ycombinator.com/item?id=44025635
| (unrelated to Magit)
| captnasia wrote:
| to give another jujutsu ui, I use jjui which works well for me
|
| https://github.com/idursun/jjui
| hypersoar wrote:
| 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.
| iib wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 souffle 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(tm), 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 souffles, and things that don't even
| have names yet.
|
| The cookie-kit users are still arguing about whether round or
| square cookies are "correct," while I'm over here making
| star-shaped ones because I felt like it today.
| reddit_clone wrote:
| >Maintaining a complex Emacs config is a chore. I have
| given up and adopted Doom Emacs. Let cleverer people do the
| wrangling
| cmrdporcupine wrote:
| I feel like Doom is maybe obsolescent on account of
| standard out of the box emacs having fairly easy to set
| up these days, with themes and LSP and etc just there out
| of the box and package-install just working.
|
| But also I have absolutely zero desire to run with modal
| keybindings, which seems to be Doom's schtick.
| kstrauser wrote:
| That's also why I don't use it. It's not _bad_ at all! It
| 's just not how _I_ want to use Emacs. It 's not right
| _for me_.
|
| I sure do get the appeal of an out-of-the-box Emacs setup
| that does everything with modern defaults, but the base
| installation gets better, more ergonomic, and more
| powerful by the year on its own.
| iLemming wrote:
| "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.
| iLemming wrote:
| 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.
| qyron wrote:
| Seeing all the praise for Magit in these and numerous other
| threads, could someone please elaborate on its standout
| features that are missing from other editors/IDEs
| (VSCode+extensions or JetBrains)?
|
| For example, in my current VSCode + GitLens setup (must admit
| that I have a corporate license for GitKraken, which enables
| full GitLens functionality). I use these features 99% of the
| time.
|
| 1. Convenient diff/merge with character-level diffs and visual
| indication of moved code.
|
| 2. A graphical commit tree with filtering, searching, numerous
| hovers with lots of information, and buttons to quickly jump to
| all sorts of diffs.
|
| 3. Interactive rebase (GUI for selecting those
| pick/squash/reword etc.)
|
| 4. Editing new and existing commit messages in vscode, which
| allows me to use better commit message formatters, LanguageTool
| and LLM extensions for rewriting/paraphrasing.
|
| When I see comments like "Magit is the only thing that keeps me
| from leaving Emacs," I honestly wonder what they're going to
| miss.
| iLemming wrote:
| > 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.
| qyron wrote:
| 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?
| tretiy3 wrote:
| Looks good! Shameless plug: i am building my own standalone linux
| only version https://github.com/aganzha/stage
___________________________________________________________________
(page generated 2025-05-29 23:02 UTC)