Technically most modules would work with node.js as they are not using any bun specific APIs. The reason for crust to be all in bun is because bun can compile your cli into binaries for distribution which powers curst build. The idea is that since you will have bun bundled with your CLI to end user. the developer does have to worry about the end users don't have bun installed and use Bun api freely when building.
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.
> 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.
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?
> 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.
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.
> 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.
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.
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.
I share all criticism on the subject but I must admit there is a killer feature that alone converted me to use Edge on MacOS - native vertical tab bar with tab grouping. It worked much better for me than all Chrome and Firefox extensions I tried before.
I know Brave implemented it recently too so Edge is not the only player in town now, but it was the first! Hopefully the rest of browsers will follow the trend.
More powerful does not necessarily means better. Vivaldi indeed allows much more customization, but for my tab-heavy browsing pattern Edge's (and now Brave's) way suits much more. For example some things I don't like in Vivaldi:
- No colors. In Edge/Brave new color is auto-assigned when creating new tab group and can be overridden at any time.
- When tab group is expanded, the group name/header is not shown. When you have many groups with similar tabs they are much less visually distinct from each other.
- Moving new tab to one of previous collapsed groups can be easily done via context menu in Edge. In Vivaldi you'll have to expand the group and drag the tab.
These are all minor inconveniences but together they make a big difference.
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.
Firstly, your VST situation will be that the plugin, the host or both are not implementing things correctly: one or the other has claimed DPI-awareness inappropriately. That’s on them.
Secondly, you misunderstand the relative situations of macOS and Windows. The difference is not to do with their approach to scaling, but rather their approach to supporting old software, and the diversity of hardware. Social factors, not technical. Apple could absolutely have done fractional scaling, and it’d have worked just fine for them; the present situation in how well high-DPI stuff works across platforms would be indistinguishable: macOS would still have basically nothing broken, and Windows would still have quite a few widely-used pieces of software getting it wrong. Here’s why:
Apple developers are very probably using a high-DPI screen, so they’ll immediately notice if anything is off. Apple is controlling, and anything published through their store will have any obviously-bad scaling noticed and rejected. Apple doesn’t care about long-term compatibility, so earlier software that didn’t implement scaling properly largely just doesn’t run at all any more.
Windows developers are probably using a low-DPI screen, and are publishing to a largely unmoderated platform that still has software from decades ago run just fine.
Functionally there’s no difference between fractional and integral scaling in how well software will support them. If you try to implement things completely from scratch, fractional will be a little harder because you have more rounding decisions, but in practice you always use a library that takes care of that for you (normally a full widget toolkit, but VST plugins will often use something somewhat lower-level but still above the physical-pixels layer except when you deliberately opt for fine control), so there is literally no difference at all. The difference in how well things work on these different platforms is purely other factors.
I consider myself pretty advanced user of Tabnine, having purchased the first version from Jacob just when it appeared. I haven't used (and don't plan to) its full-function code completion and only briefly evaluated Copilot. Some thoughts:
- Tabnine's local per-repository model shines best when used on big monolithic repos with lots of similar or boilerplate code. By learning on the same code it's used for it IMO does much better job at detecting local patterns. Also local-model means pretty "safe" from security POV for corporate use (I can't imagine big corps like Google and Amazon allowing use of Copilot for proprietary code).
- Back in they free tier of Tabnine was pretty useless compared to Pro because it severely limited model size. If it's still the case now I hope they have a long evaluation period.
- From usability POV, unfortunately it doesn't provide non-intrusive experience out of the box, which is very annoying and I believe is a reason for many users abandoning it pretty quickly. I had to modify both VSCode extension and VSCode itself (!) so that Tabnine's completion suggestions won't interfere with others.
Appreciate the feedback and looks like you are clearly in the developer group that wants very fast small useful completions. Can you share the modifications that you made and perhaps a few more details on what they were?
Both are related to limitations of vscode completion engine, so Tabnine can't really blamed for them in any way.
1. Initially Tabnine's auto-completion was triggered on any character, which best leveraged Tabnine's power but also had inherent problem: when Tabnine was triggered on non-letter character it sometimes prevented Vscode from showing suggestions from other completion sources (LSPs, snippets). There is a discussion in https://github.com/codota/tabnine-vscode/issues/6 with me explaining that the only viable solution is to reduce set of trigger characters to letters only. In the end a fix was pushed that reduced the set of trigger characters, which made the problem less likely but still not solved. The are numerous duplicates of this issue on Github.
2. Another problem is when Vscode has auto-completion suggestions from Tabnine and other sources (LSP, snippets), it frequently puts Tabnine's at the top of list. This is a big no-go for me because most of the time just want to complete the identifier (class field, method etc.). Modifying just the extension code didn't help so in the end I had add a small patch to Vscode itself, which gives lowest score to Tabnine's candidates: https://github.com/sergei-dyshel/vscode/commit/ee73034b9ec6c....
I must admit that both problems can be practically solved by new "inline auto-completion" mechanism in vscode which looks very promising for AI-based completion in general. I'm looking forward to evaluate it.
Using Ergodox and Moonlander on daily basis. I think most of gain in my case comes from the the keyboard being split, staggered layout, programmable etc.
Mechanical switches are just nice bonus. Of course it's fun to try different switches, keycaps, o-ring and pimp the keyboard in some way but I don't think it boosts my productivity in any way or helps with RSI....
About a year ago I was deciding between Kitty and Alacritty and I chose Kitty because of 2 important features it had over Alacritty: proper underline rendering (Alacritty just draws underscores) and text selection with Shift+Mouse. Kitty also compiles instantly as it's written in plain old C. The author is also very responsive on GitHub and addresses each issue quickly.
Does ZapCC provide libclang.so which utilizes this caching?
I noticed that parsing heavy-templated files with clang-based tools is also very slow which probably means that some kind of template instantiation (or other processing step) is being made. These tools could greatly benefit from any speedup.
While reported 2x average speed-up may be not big enough for me to consider ZapCC for offline compilation, 2x less time to get list of completions in Clang-based IDE is something I would be very happy to get!
Can't agree more! With all respect to Alacritty, I find Kitty easier to install/update, having more features and at least comparable performance (as it also uses OpenGL for rendering). Overall it seems a pretty mature product and the author is very responsive to Github issues.
I'd like to see it more in these terminal-related articales and discussions...
