The implementation is probably different.

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?

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.

Comments URL: https://news.ycombinator.com/item?id=38015484

Points: 2

# Comments: 0

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

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.

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.

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

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

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!

I'd like to see it more in these terminal-related articales and discussions...

Regarding indexing time, all of these tools seem to parse source code using either libclang (C API) or "native" C++ API (RecursiveASTVisitor etc.), so IMHO any difference in indexing time between rtags and cquery should come from such factors as number of parsing threads, database for storing tags, caching etc.

Anyway I'm really excited about cquery and even consider moving to VSCode just because of it (being a long-term VIM user). Reliable "Find references" feature is (IMHO) a must-have functionality for large codebases and currently (thanks to cquery and rtags) is supported much better in modern C++ than in other system languages (such as Go and Rust).