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?
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.
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 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.
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.
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.
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.
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...
I've been happy user of ycmd+rtags tandem for a couple of years. A killer feature of rtags me is its ability to run server on remote machine (of course source code must be mirrored too). This allows me to do develop on my weak 4-core laptop and offload indexing to fast 32-core workstation.
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).
Now interface works well. But still no connection. I've tried both cellular internet (where UDP is most probably blocked) and home WiFi which doesn't block UDP (for sure, I tried pinging from phone).
On the first blank screen I try to input "soft1", then I see some sort of connection dialog but then I get error message which, again, is not visible. Attaching link to Dropbox folder with screenshots. https://www.dropbox.com/sh/tagc4veaeco8umm/AAA2xcvvLQoM_lUh1...
