HackerTrans
TopNewTrendsCommentsPastAskShowJobs

qyron

no profile record

comments

qyron
·지난달·discuss
Can you explain the joke?
qyron
·4개월 전·discuss
Any plans to support Node.js? Also some comparison (at least design choices) with existing frameworks would be nice.
qyron
·8개월 전·discuss
One difference can be seen right away - when moving a window, border made by JankyBorders moves smoothly together with window, unlike with this app.

The implementation is probably different.
qyron
·작년·discuss
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?
qyron
·작년·discuss
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.
qyron
·4년 전·discuss
I don't really know how HiDPI is implemented on Windows, but I do know some very popular VST plugins (music production software, which usually uses its own GUI and scaling integration) which still doesn't scale properly in popular plugin hosts, so you can't really talk about "getting it right in all circumstances".

This problem doesn't exist on Mac where the OS is kind of responsible for all the scaling. So, between MacOS's approach which may be not pixel-perfect but "just works" and Windows's one which usually works perfectly but still has problems in certain categories of software, I'll probably choose the former.