[qyron]

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?

[sameerds]

> 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.

[iLemming]

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.

[boops_u]

> 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 :)

[iLemming]

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.

[jasonm23]

It's beautiful and why there's not all that many Emacs users... it requires a commitment, at the very least.

[iLemming]

> it requires a commitment

What serious tool doesn't?