131–140 of 144 posts
The best part - it's a TUI program that's usable independently, that also happens to embed really well within vim.
I use magit daily for over 8 years now. Over that time I have showed it to many other peers, out of excitement for a tool that made me more productive and helped me learn - but I never could convince even one to use it. Maybe it's my persuasion skills, maybe tool usage is too personal - I don't know, but it makes me kind of sad. The UX of magit is just out of this world. Especially for rebasing, subset rebases (using…
Magit is absolutely the best Git GUI ever. Unfortunately, for most people the fact that it's part of Emacs is a blocker. And because most people use worse Git tools, they tend to use workflows that are easier with more cumbersome tools; generally just committing all kinds of junk commits to a branch, and using the "squash and merge" feature of GitHub or GitLab to clean everything in a PR/MR up into a single commit. S…
Not even close. Claude and codex are the best git gui.
Earlier quoted context omitted.
Emacs is my editor/IDE of choice and consider myself power-user. However, I'm no expert in its internals or elisp. I understand that things are built with single-thread execution in mind over decades. However, I think things still can be more async, where you can offload heavy stuff to separate thread and stream results. E.g. Magit status doesn't need to block my entire editor. It can run what it needs to do in separ…
Probably all true, what you say about magit and so on. Message passing values would be an idea, but with the current situation, when 1 concurrent execution units, a process, finishes its job, how does its "private" potentially modified state get merged back into the main Emacs global state? Lets say the concurrently running process creates some buffers to show, but in the meantime the user has rearranged their window…
>> What is the problem with mono repos?
If you use things like that depend on something like ivy/vertico/... find-file-in-project, projectile-find-file, ripgrep gets super slow (I think the reason is that they usually wait for entire result to be ready). LSP/Eglot gets slower. Similarly, will have to disable most of VC related stuff like highlight diff on fringe. Git will be inherently slower, so magit will hang your UI more often. Of course you can disable all these plugins and use vanilla emacs, but then if you remove enough of them you're likely going to be more productive with VSCode at that point.
Just to clarify this is experience with monorepo + tramp. Also not sure how much of its just plugins fault. Somwhat better if you use emacs locally where the monorepo is, however that often means using Emacs cli -- which usually means lose some of your keybindings.
Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…
You tell emacsclient which file to load and to which line to jump to. For me that's `e file.ext:200` expanding to a emacsclient call.
Earlier quoted context omitted.
one thing I'm missing in jjui which jj cmdline does natively is rebase onto multiple heads - using this for quickly testing my branch on some other pr and latest main. other than that agreed, helps a lot with tedious noting down of change id prefixes.
you can do this by using the "set parents" operation (shift+m) which allows you to add/remove parents to a revision. https://idursun.github.io/jjui/revisions/set-parents/
Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…
Startup time does not matter, use the daemon. Opening a new frame is ~instantaneous. I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest! There's a new branch (feature/igc) with incremental garbage collection (via MPS) that makes routine actions faster. I've been using it and it has been incredibly stable and has completely eliminated stutters (which used to happen v…
yeah, that's been my experience as well, particularly since upgrading to releases 29 and 30 where native compilation was enabled by default.
honestly the only place where it's slow it's when i'm editing terraform files, but that's because it needs to boot the terraform language server, and only on the first file of the project.
Earlier quoted context omitted.
one thing I'm missing in jjui which jj cmdline does natively is rebase onto multiple heads - using this for quickly testing my branch on some other pr and latest main. other than that agreed, helps a lot with tedious noting down of change id prefixes.
you can do this by using the "set parents" operation (shift+m) which allows you to add/remove parents to a revision. https://idursun.github.io/jjui/revisions/set-parents/
Earlier quoted context omitted.
Nah. Here's a counter example: the TUIs that IBM wrote for many old store chains like Home Depot. They're at least an order of magnitude faster to operate for cashiers compared to web UIs but they're somewhat slow to start due to the caching and self-checks they do. This obsession with quick boot is more of a personal preference you have than a necessity.
An inane point. Obviously it's a "preference" rather than a "requirement" that my text editor boot in less than 30 seconds. But it's also not a functional requirement that Home Depot's POS terminals take a long time to start. If you could do the same checks and caching in a few hundred milliseconds it would only improve the usability for the cashier. You haven't made a case for why some user interfaces shouldn't star…
No it wouldn't. Those interfaces are permanent and only get restarted once a day or if the hardware has to be rebooted. Same for Emacs: there's absolutely no need to start the editor every single time.
> You haven't made a case for why some user interfaces shouldn't start instantly
I'm not making any case, we're not in court. Startup time is irrelevant and your fixation with it is really funny (up to a point).