Rendered at 05:21:01 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mschulze 15 hours ago [-]
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 --onto, see https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_...) are a breeze with Magit. I can't remember the order of branches to use on the CLI, in Magit it's just "r s" basically. It's really magic.
lambda 15 hours ago [-]
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.
So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI.
0x1ceb00da 30 minutes ago [-]
> Magit is absolutely the best Git GUI ever
Not even close. Claude and codex are the best git gui.
w4rh4wk5 14 hours ago [-]
I've looked at Magit and indeed Emacs is a blocker as it's not something I'd like to pick up and maintain. I am using Fork as my primary Git GUI and am pretty happy with it. Lazygit and tig cover the few use-cases which Fork does not cover.
zelphirkalt 13 hours ago [-]
I am not someone to recommend VSCode, but if you are already using it, you could check out edamagit. I think in the Vim world there is also some equivalent.
MobileVet 8 hours ago [-]
Run spacemacs in ‘evil mode’ so you can use Vim!
moritzwarhier 11 hours ago [-]
Personally, I'm not a Git magician, but I prefer the Git CLI for most operations.
Only exception is resolving conflicts.
The most important point for every gut IDE integration to me is that it cleanly maps to the file system and CLI state.
mr_mitm 10 hours ago [-]
Staging single lines or hunks is also much easier in a TUI/GUI. I wouldn't even know how to do it with just git.
stackbutterflow 10 hours ago [-]
git add -p
kirici 8 hours ago [-]
Operates on hunks, which may at times be multiple lines that cannot be split further
yacin 2 hours ago [-]
oftentimes splitting the hunks with `s` is enough.
throw-the-towel 7 hours ago [-]
You can edit a hunk with `e`. Clunky but it works.
nothrabannosir 2 hours ago [-]
In a conversation about magit, this is comparing jumping off a sidewalk to powered flight.
10 hours ago [-]
saila 13 hours ago [-]
Good tools can improve your workflow for sure, but it's easy enough to keep a clean history with a handful of git commands. There are two main reasons people don't do so: 1. they don't know the commands yet or 2. they just don't care (and are in an environment where there's no incentive to care).
The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available.
hrmtst93837 9 hours ago [-]
Magit is more than a shortcut for command avoidance. It helps surface conflicts and edge cases during complex rebases and fixups, especially on big feature branches, making problems visible earlier. Relying on muscle memory alone can lead to mistakes, and using better tooling can limit the fallout when that happens.
znpy 13 hours ago [-]
> Unfortunately, for most people the fact that it's part of Emacs is a blocker.
OT but i've learned the hard way not to push people into emacs.
a few years ago i made the very stupid mistake of pushing some colleague to trying/learning emacs and then i found myself having to explain the same person everything as well as fix his elisp code from his ~/.emacs .
Reality is, i didn't want to have that role and that colleague wasn't interested in gnu emacs in the first place.
That was a very stupid mistake on my side.
Nowadays i just say things like "yeah it's magit, an emacs plugin" or "ah yeah, it's nice because you spend some time learning it and then you can bring it over from company to company, no licenses involved or other annoyances".
Some people are intrigued, most other absolutely aren't... And it's fine.
kqr 12 hours ago [-]
Surely the mistake here is conflating "learning Magit" with "learning Emacs"? I can run Java applications while knowing nearly nothing about the JVM. The same is true for applications based on Emacs.
tsimionescu 10 hours ago [-]
Magit is not an "application based on Emacs", it's an extremely powerful git plugin for someone who is already using Emacs. If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase. Even the fact that you'd have to learn Emacs' extremely idiosyncratic keyboard shortcuts, and even keyboard shortcut help (what do you mean "save is C-x C-s?" what does that even mean?) is a huge problem not worth the effort.
And I'm saying this as someone who has exclusively programmed in Emacs with Magit for the last 5 years in my job.
kqr 8 hours ago [-]
> If you're not using Emacs, it would be crazy to fire up Magit just to do a git commit or rebase.
What makes you say that?
> what do you mean "save is C-x C-s?" what does that even mean?
Magit never asks you to C-x C-s save anything. Magit has its own independent set of discoverable keybinds.
steve1977 12 hours ago [-]
One does not simply use Emacs.
worik 10 hours ago [-]
I simply used Emacs for 25 years, avoiding editing .emacs entirely
Only in the past years have I started customizing it
My attraction to Emacs is stability and I can use it in text or GUI mode.
Many editors have come and gone in that time, many employers insist I use this or that piece of over designed, under done GUI. When I have the chance, back to Emacs
badsectoracula 9 hours ago [-]
> Magit is absolutely the best Git GUI ever.
But it isn't graphical :-P.
Personally i've been often looking for an opensource Git GUI front end but couldn't find anything i'd like. My points of reference of decent tools -ignoring the underlying tech- are Perforce and TortoiseSVN under Windows and Fuel[0] (for Fossil) and KDESVN under Linux.
Perforce and Fuel are the two i like the most, followed by KDESVN and Tortoise. But since i'm on Linux and i stick with opensource projects, Perforce and Tortoise are out, leaving me with Fuel and KDESVN. I'm using KDESVN for a few projects where i don't care about external collaboration and want to store many binary files (which Subversion does it better that Git IMO), though KDESVN is very primitive and limited in what it supports (it doesn't support shelving at all, for example - in fact for anything beyond commit and checking the history you probably need to use the cli tool). I do not use Fossil much nowadays but i used it a lot in the past so i have a bunch of repositories in it, for which i use Fuel. Fuel is unfortunately not being developed anymore, though since it is opensource it doesn't matter much (which is a reason why i ignore anything non-opensource, i know there are some decent proprietary Git clients but for me they might as well not exist).
I think at some point i'll grab libgit2 and make something using Lazarus, probably something similar to Fuel. Unlike libsvn, which seems to be made in hell, libgit2 seems very sane and shouldn't be terribly hard to make something usable out of it.
In the meanwhile i use a combination of git cola, gitgui and gitk though they all feel like a hodgepodge of barely thought random features thrown in together (and i hate that they all want to impose their own idea of how i should format a message -especially git cola- which of course aren't identical between of them and aren't even close how i'd like to format the messages myself).
Peculiarly, having used Emacs for a decade as my main editor, and Git for much more than that, I never could get used to Magit.
Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command.
This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving.
It's Mac-only. That's a pretty serious limitation for a modern Git tool.
ileonichwiesz 11 hours ago [-]
Isn’t this just something that any IDE has built-in these days? Maybe I’m missing something, but how is this fundamentally different from the built-in git timeline view from something like VSCode or Jetbrains?
troupo 7 hours ago [-]
> Isn’t this just something that any IDE has built-in these days?
In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too).
I upvoted you because you were unfairly downvoted. I don't even use a Mac any more after 20 years of exclusively using them but it's actually hilarious how bad magit is compared to this. It's all well and good making the most of limitations that are self imposed but people need to remember to look outside their own bubble.
znpy 13 hours ago [-]
> I don't even use a Mac any more after 20 years
So the software is mac-only, you haven't used a mac in over 20 years so you haven't used this software and yet... you claim it's better than magit?
i mean, it's very dishonest at best.
BeetleB 12 hours ago [-]
> you haven't used a mac in over 20 years
Not what he said. You misparsed.
troupo 13 hours ago [-]
The claim was that its GUI is better than Magit's, following this claim: "Magit is absolutely the best Git GUI ever."
lambda 12 hours ago [-]
It may be prettier looking. I've seen many Git GUIs that are prettier than Magit.
But none of them that I've tried have ever come close to the workflow.
I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.
troupo 7 hours ago [-]
> I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts.
My most common workflow besides staging anything is (to make sure history is clean):
- split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit)
- move new commit up/down the branch (doesn't require interactive rebase in GitUp)
- squash up/down
(undo/redo from time to time)
As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent
> Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2]
However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason.
[2] There's another downside to GitUp: it's very slow on repos with huge histories. Probably due to the git library it's using.
masklinn 15 hours ago [-]
I personally don’t care for rebasing in magit (I actually find it confusing when hitting conflicts).
My primary reason for using it is reviewing and staging commits. The non-linear staging with line granularity (which also lets you revert changes at the same time) is so, so very good when you care about crafting commits.
mschulze 15 hours ago [-]
Right - actually, for conflicts I switch to IntelliJ.
taude 15 hours ago [-]
I used to use Magit, but once I discovered LazyGit four years ago, I never looked back. No Emacs bloat and a great TUI-based UX with quick single key press actions.
ziml77 6 hours ago [-]
This is what I need to be sold on magit over. Magit just feels slower (and definitely is slower to start if you're not already in emacs) and less intuitive.
jwr 14 hours ago [-]
> I never could convince even one to use it
Most people think it's "just another interface on top of git" — without several in-depth examples it's difficult to realize that it actually allows you to complete really complex tasks quickly. I've seen this superficial take many times.
sureglymop 12 hours ago [-]
It looks really cool but the thing is, having learned git just as a cli tool, I don't think any UI would convert me from that workflow.
The exception is maybe diffing, where I just use meld as the difftool.
rgoulter 4 hours ago [-]
I think you're missing out on magit.
With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy.
For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit.
Or magit makes it easy to stage/unstage line by line.
zelphirkalt 13 hours ago [-]
Same experience here. Showed it to coworkers, but none was interested in making their tooling work well. Even looking for a VSCode equivalent for them (edamagit) no one was even willing to try. Yet people complained about many branches in repos, which didn't impact me at all, but for their GUI git clients apparently were a problem, and so we switched to deleting branches upon merge, discarding some git history along with that (when something was merged).
e40 9 hours ago [-]
My exact experience, though I did learn it from a co-worker, so at least he did succeed. :)
jayd16 15 hours ago [-]
What makes something easier in magit than, for example, SmartGit?
mschulze 15 hours ago [-]
I haven't used SmartGit, so I can't really compare.
I would single out the following for Magit:
1. Single key strokes for actions and toggles
2. Discoverability through "slide-ins" (TFA also explains this)
For 2, this means I press "c" for commit, this opens a popup showing me the next keypresses and what they do.
So I can build up muscle memory for commands I know that are fast due to 1, and I can discover options that might help me due to 2.
If I don't know what to do at all, there's Ctrl+c, Ctrl+c to discover "entry-points" for Magit shortcuts.
zelphirkalt 13 hours ago [-]
I would also highlight that in Emacs magit one can always drop back to command line by pressing "!", which I do, when I don't know how to do something in Magit. Like "git submodule update --init --recursive".
erksa 15 hours ago [-]
Same, emacs being the barrier for most.
Perz1val 11 hours ago [-]
I'll never touch any git wrapper, because they've lied to me before and I can use git already. Everything that was there to be sped up has already been made into zsh functions.
jonpalmisc 15 hours ago [-]
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 -es --cmd 'vim.cmd("q")' 0.02s user 0.01s system 82% cpu 0.034 total
Even with a very minimal set of packages, text insertion, etc. is slower, and opening Magit (when it hasn't been loaded yet) takes about a second due to slow package loading.
Emacs is my favorite editor, full stop.
But every time I open Neovim or Sublime for quick tasks, it's always painfully apparent how much faster they are when I CMD+Tab back to Emacs.
zelphirkalt 13 hours ago [-]
Emacs' hard to solve issue is its use of global mutable state all across the board, which makes concurrency and parallelism very hard to add properly. It will take a lot of effort to slowly carefully reduce the error/bug surface and add proper parallelism constructs, that are easy to use for any package author.
truncate 9 hours ago [-]
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 separate thread, send the results back to main thread just for rendering when its ready. Same with say consult-ripgrep / consult-find-file / find-file-in-project etc -- doens't need to wait for it in main thread and block the render / event handling until entire result set is ready (e.g. in this case things can be streamed). As in maybe there is a way around to make this much better by message passing/streaming instead of sharing state itself?
I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.
zelphirkalt 5 hours ago [-]
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 windows or split their view, but the concurrent process doesn't know about that, since it was after its creation time. Or maybe the user has meanwhile changed an important Emacs setting.
I think the current solutions for running things in separate threads are only for external tools. I guess to do more, a kind of protocol would need to be invented, that tells a process exactly what parts of the copied global state it may change and when it finishes, only those parts will be merged back into the main process' global state.
Maybe I understood things wrong and things are different than I understood them to be. I am not an Emacs core developer. Just a user, who watched a few videos.
Tramp can be sped up a bit. I remember seeing some blog posts about it. I guess if you need to go via more than 1 hop, it can get slow though.
What is the problem with mono repos?
truncate 28 minutes ago [-]
Yes, totally agree that its not always applicable. But I think there is still lot of scope to offload some operation (e.g. magit operations like status, commit, streaming search result into minibuffer in ivy-mode). Having a dedicated protocol would of course be best (VSCode Remote works flawlessly for me).
>> 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.
Ferret7446 11 hours ago [-]
Emacs is functionally a shell not an editor. Starting Emacs for each file is akin to starting and stopping Wayland for every web page you open.
So the miniscule increase in start time is a non issue
ishouldbework 15 hours ago [-]
While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.
jonpalmisc 15 hours ago [-]
Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow.
Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.
chriswarbo 14 hours ago [-]
> I think having a globally shared buffer state, etc. is an antifeature.
As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of.
It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)
finaard 12 hours ago [-]
The slowness on startup in my emacs mainly comes from my customizations - over the last almost 3 decades I've accumulated roughly 30k loc of custom lisp, plus a lot of 3rd party stuff.
But I typically start emacs at boot, and then it runs until I reboot. I usually have one GUI frame, and one tui frame running in tmux so I can easily attach to my emacs session from a different computer. I have an emacsclient wrapper that opens stuff from the command line in my running emacs (and also mail wrappers, so clicking on a mail link in a browser opens a mail compositor in emacs).
I'm using eyebrowse with a bunch of own convenience features for workspaces in emacs - stuff like "when I switch to a buffer it'll switch to the workspace wher e that buffer is open unless I tell it I want it here". Combine that with some custom SSH entry points and especially on the notebook where I only have one screen it's way more comfortable to use than the OS window management for a terminal/ssh session messy like me.
ragall 13 hours ago [-]
> Plus, there's no reason that starting a TUI program should be that slow.
There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.
jonpalmisc 13 hours ago [-]
> You seem to think that the interface obliges a program into a certain performance pattern.
I think all software (or at least, any text editor) regardless of interface type should launch instantly. But it's more unjustifiable with TUI programs.
ragall 11 hours ago [-]
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.
qubidt 8 hours ago [-]
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 start instantly, only that their slow start-up _might_ be justified
dietr1ch 14 hours ago [-]
> having a globally shared buffer state, etc. is an anti-feature
Yeah, it feels a bit weird to not have some isolation.
Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default).
Emacs has globally shared buffer state amongst the frames that share the same "base frame" (no idea what this is called) or the same socket (could be wrong here).
Anyway, you can start N emacs instances and they can all have individual buffer states.
Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.
Text insertion lag is something I haven't experienced since 2019. Config issue?
project-find-file might be slow because of low gc-cons-threshold. I know consult gets around this by temporarily raising the threshold. These days, you can use the feature/igc branch to make these operations faster (although they are pretty fast anyway).
If you think emacs lacks <fundamental feature X>, think again!
MereInterest 11 hours ago [-]
> Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.
Can you elaborate on this? I tend to use emacs exclusively in the terminal, since I'm often using them on remote workstations. For remote workstations, I can (a) open files using TRAMP, (b) open a remote GUI with X11 forwarding over SSH, or (c) open a remote TUI. TRAMP doesn't always play nicely with LSP servers, and remote TUIs are much, much more responsive than X11 forwarding.
Locally, the performance of emacs depends far more on the packages I load than on the GUI vs TUI, so I'm interested in hearing what overhead there would be.
precompute 8 hours ago [-]
Yes, emacs is equally performant in GUI and TUI. And frames can be opened in both GUI and TUI on the same socket.
For me, TUI is a dealbreaker because:
- No mixed-pitch support: I use mixed-pitch fonts in org-mode buffers and in outline faces in prog-mode buffers. And fonts are just plain nicer on the GUI, and it's much better to look at.
- No SVG support: (I might be wrong about this) I have a custom modeline with SVG artifacts and the artifacts fail silently on the TUI
- Keybind conflicts: I am not used to accounting for the terminal's keybinds. Also, I use xfce4-terminal, which does not support the Hyper modifier (which I use extensively).
smitty1e 14 hours ago [-]
> I think having a globally shared buffer state, etc. is an antifeature.
Maybe, but I'd like to hear why you think this is such an antifeature for a single-threaded application.
Given the extra resources available these days, for example, why not just bring up a stand-alone ERC instance for chatting, if shared state is a concern?
spudlyo 14 hours ago [-]
On my M1 Mac Pro I get 0.13s wall, so not much faster than your Mac. On my i9-9900K Linux box I get 0.04s. I would think my M1 single core performance would be on par, if not faster. Perhaps it has something to do with macOS and gatekeeper, as I notice I'm not getting as high of a CPU utilization.
GUI Emacs on a 12 year old processor (i5-4590) feels faster than on a M4 Pro Macbook. I think it's just something to do with the window manager on each of the systems (my experience is mostly with Wayland KDE) rather than the speed of the CPU.
spudlyo 13 hours ago [-]
I also run GUI Emacs on both Linux and macOS. I build it on Linux with --with-x-toolkit=lucid and for $REASONS I'm still on X11. I run it in a full-screen frame on its own monitor, and it does indeed feel faster.
chriswarbo 14 hours ago [-]
Emacs can certainly be sluggish, but I'm not sure how much that's e.g. inherent to ELisp, or due to synchronous/single-threaded code, or choosing slow algorithms for certain tasks, etc.
For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect.
Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!
dietr1ch 14 hours ago [-]
> Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting
I agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]).
I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down.
On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX?
$ time emacs -Q -e kill-emacs
real 0m0.076s
user 0m0.058s
sys 0m0.018s
$ time nvim -es --cmd 'vim.cmd("q")'
real 0m0.028s
user 0m0.005s
sys 0m0.003s
vim still is a lot faster though.
znpy 13 hours ago [-]
> On my old Ryzen 3600X running Arch
> vim still is a lot faster though.
you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all.
maybe try with a non-gui version of emacs (or maybe calling emacs -nw)
Joe_Cool 12 hours ago [-]
no, this is the TUI version.
X11 emacs with all the composited effects needs about 200-250ms to open (about the duration of the animation for opening and closing it). That's more like OP's timings.
codygman 12 hours ago [-]
No, you need to use -nw with emacs to make it apples to apples. Then it's emacs 0m0.095s vs nvim 0m0.057s:
$ time nvim -es --cmd 'vim.cmd("q")'
real 0m0.057s
user 0m0.016s
sys 0m0.017s
$ time emacs -Q -e kill-emacs
real 0m0.230s
user 0m0.165s
sys 0m0.064s
$ time emacs -nw -Q -e kill-emacs
real 0m0.095s
user 0m0.057s
sys 0m0.017s
Joe_Cool 12 hours ago [-]
Shouldn't matter when I am not on GUI seat. In my SSH session with X11 forwarding there is no DISPLAY emacs could use.
Tried it anyways, looks the same:
$ time emacs -nw -Q -e kill-emacs
real 0m0.075s
user 0m0.062s
sys 0m0.013s
Joe_Cool 8 hours ago [-]
s/with/without/
ahoka 15 hours ago [-]
/usr/bin/time emacs -Q -e kill-emacs
0.03 real 0.02 user 0.00 sys
Altough I'm not using Emacs.app.
jonpalmisc 15 hours ago [-]
Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.
weaksauce 11 hours ago [-]
my non-command line gui version of doom emacs with a bunch of packages enabled loads up fully for me in 0.45s which is hardly slow. sure it's slower than neovim but also not slow in the absolute sense and i don't have the emacs daemon running which would make that even faster.
8s2ngy 14 hours ago [-]
I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.
umanwizard 14 hours ago [-]
There would be no point to writing emacs in a language that can’t be developed interactively in a repl. Emacs being written in lisp is an essential quality.
BigTTYGothGF 14 hours ago [-]
> Emacs being written in lisp is an essential quality
Not for the parts of it I use.
precompute 13 hours ago [-]
>a lot of cruft
Like what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.
umanwizard 13 hours ago [-]
The vast majority of emacs is written in lisp, not C.
BigTTYGothGF 14 hours ago [-]
I'm not sure I'm capable of noticing or caring about the difference between 0.18 and 0.02 seconds for something that doesn't happen on a rapid cadence.
precompute 13 hours ago [-]
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 very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.
chriswarbo 14 hours ago [-]
I've been using magit for years, and it's the reason I avoided giving the jujutsu VCS a try: the `jj` workflow/UI is supposedly much nicer than the `git` workflow/UI; but since I use magit more than bare `git` commands, that wasn't enough to sell me.
I finally gave it a try when I came across the majutsu package, which is a magit-like interface for jujutsu. I recommend it for Emacs/magit users wanting to try `jj`!
tcoff91 13 hours ago [-]
I really love the jjui TUI. For non-emacs users who want a great TUI for jj definitely check it out.
baq 12 hours ago [-]
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.
Zambyte 12 hours ago [-]
This is something I've never done before. Are you just repeating -o, creating a merge commit?
If that's the case, it also seems like you can do jj duplicate and repeat -o if you just want to create a branch to temporarily test against another branch and main.
baq 11 hours ago [-]
yes, exactly this, multiple -o. I sometimes have two or three branches which I keep a single merge branch on top of and being able to switch out the parents is super convenient.
I'm still learning jj, so I'm not sure about jj things that majutsu might be missing, or what git/magit things seem "missing" but are just done differently in jj.
A couple of things I tend to notice:
- In magit, I can run a raw git shell commands by pressing `:`; majutsu doesn't seem to have that, so I use Emacs ordinary `M-!`
- The default view in majutsu (log) isn't as slick as magit's. With magit, I'll routinely open it up to look at the repo status, browse through the diffs (expanding/collapsing), staging/unstaging, etc. With majutsu, most of that requires first opening up the log, then opening up the diff of a commit.
- Staging/unstaging in magit is quite nice. The analogous workflow in jj seems to be splitting/squashing, but that feels clunkier in majutsu.
I've not opened bugs or PRs for these things, since it's mostly vibes and I don't have actual solutions to offer ;-)
EDIT: Oh, I also remembered that `jj` ignores $PAGER and uses its own built-in paging by default. That tries to act like `less`, and doesn't work well in Emacs. It can't use env vars either, unless we set its pager to something like `sh -c "$PAGER"` (see https://docs.jj-vcs.dev/latest/config/#pager ). Since my $PAGER is always `cat`, I've just set that as jj's pager directly too.
The Emacs interface in general isn't massively like Lotus 1-2-3's, but magit's somewhat is. The above post goes into a bunch of detail, but what I remember most about my time using 1-2-3 (a long time ago now) was that the shortcuts were super easy to get accustomed to, because there was a prompt of some kind every step of the way. magit's rather similar prompts work well in this respect too. (Though you do still have to know how to use git. This is git, after all.)
Where there might be some more general overlap with Emacs: an apparent goal of Lotus 1-2-3 was, like Emacs, that its users would be able to automate it, and without too much bother given their knowledge of how to operate it in general. It's actually better than Emacs in this respect, because the macros seemed to be largely based on the keys you press; Emacs, by contrast, makes you jump through some hoops to figure out what the corresponding elisp for some sequence of keys might be. (The hoops are not hard to jump through! But they are there.)
(Along similar lines: Autodesk's Maya. And, to an extent, 3D Studio Max - though the scriptability there felt merely comprehensive, rather than pervasive. MaxScript was measurably less horrid than MEL though.)
jwr 14 hours ago [-]
One of my favorite magit tricks: cF (commit with instant fixup).
This lets you add a single-line change to a commit way back somewhere in the log.
aardvark179 7 hours ago [-]
cF is the command you want for this.
tambourine_man 15 hours ago [-]
Magit is one of the few things that makes me, as a Vim user, envy Emacs. And org-mode, since I'm being honest.
kqr 15 hours ago [-]
You can use Magit even if you're a Vim user. You don't have to buy into the whole Emacs system – you can treat Emacs as the virtual machine that runs Magit.
mschulze 15 hours ago [-]
Yes, I use Emacs 90% just for magit (and 10% for org-mode for some time tracking), but no text editing or coding at all.
tambourine_man 15 hours ago [-]
Yeah, but it's not as convenient.
veilrap 15 hours ago [-]
If you haven’t seen it you may want the fugitive plugin for vim. It seems to give a reasonable level of git magic within vim. Maybe not as magic as magit, but it does a lot including good handling of interactive rebases.
scocide 15 hours ago [-]
Magit was the only thing keeping me in emacs for a long time, but the neovim clone, neogit, is now 90% of the way there for my use cases, same interface same everything
codingcareer 15 hours ago [-]
Awesome! I had no idea!
I will give it a shot :) Thanks ~
tambourine_man 15 hours ago [-]
I need to move to Neovim. Thanks for the nudge.
brcmthrowaway 13 hours ago [-]
Any tips on how?
bananadonkey 6 hours ago [-]
As a magit lover, LazyGit is a fine replacement that works even better in some cases, but falls just short overall. Still very usable both inside and outside neovim.
jj with jjui is even better, coming from someone who used magit for years.
baq 14 hours ago [-]
jj/jjui should have you covered
SoftTalker 13 hours ago [-]
Magit is absolutely the only reason I'm able to use git. And even at that it's still confusing. Yes I know tens of thousands of devs use it every day. I've got some kind of mental block with git. I used to use Mercurial and Subversion without any issues.
shpx 14 hours ago [-]
I want to quit Magit because it's unbearably slow. In a repo with 6000 files `git status` takes 100ms but the Magit equivalent takes 2-4 seconds.
ashton314 14 hours ago [-]
This will probably help:
;; Speed up magit status by removing some things
(remove-hook 'magit-status-sections-hook 'magit-insert-tags-header)
(remove-hook 'magit-status-sections-hook 'magit-insert-status-headers)
(remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-pushremote)
(remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-pushremote)
(remove-hook 'magit-status-sections-hook 'magit-insert-unpulled-from-upstream)
(remove-hook 'magit-status-sections-hook 'magit-insert-unpushed-to-upstream-or-recent)
Forge36 3 hours ago [-]
Profiling[1] your own repository and tweaking as necessary (possibly
disabling auto-status refresh) will likely yield significant
performance improvements.
I use magit with a very large repository (100k files, millions of
commits) it's still not lightning fast like it is with smaller
repositories, I'm still finding it an improvement over the CLI.
My config notes this saves me ~13 seconds in git-status
It's because Magit is doing a lot more than just status. It executes multiple git commands to get all the information it wants to display.
As a sibling said, you can disable much of that.
codingcareer 15 hours ago [-]
A couple years back I was tinkering with a spacemacs setup and I loved Magit!
Over the years I opted to substitute most tools with simpler, UI-based ones (like LogSeq for org-mode) but I never found a good substitution for Magit.
Having a whole spacemacs setup just for one tool is a bit overkill though, so I just use basic git and accept having to deal with interactive rebases manually.
vvillena 14 hours ago [-]
I have a Emacs + Spacemacs setup only for Magit. The base Spacemacs config works well, so I never had the need to tinker with it. Nowadays I don't care much about the rest of Emacs. It stays out of the way, and I keep happily using Magit.
jwr 14 hours ago [-]
Magit is absolutely wonderful. It is one of the main tools I use daily to get my work done, especially now that AI does a lot of the work for me. I spend a lot of my time in magit looking at diffs!
I would encourage anyone who relies on magit to sponsor tarsius to make his fantastic work sustainable.
antonyh 15 hours ago [-]
I bounced for a while between Magit and Tig, then ended up just using whatever the IDE provided combined with the CLI. I'm a frequent-but-not-daily Emacs user, so it boils down to the friction of switching tools. I should give up the Jetbrains IDEs and go all in on Emacs.
nopurpose 15 hours ago [-]
I was missing magit, but then found `gitu` CLI and now use it happily for rebasing.
15 hours ago [-]
skydhash 15 hours ago [-]
Magit does give you a surgeon control over the scapel that git is. Most git GUI wants to give you a nice dashboard. The latter is OK if you just want some logs stored (aka git commit and git push), but version control can be a powerful tool especially considering how non linear programming can be.
A patch is an idea, not some snapshot of time. git allows for ideas manipulation. The rebase operation is adjusting ideas to fit a context. And with the reflog (which tracks every operations), you have undo for ideas manipulation.
skrebbel 15 hours ago [-]
Ilove everything about this post.
"It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"
PaulDavisThe1st 14 hours ago [-]
from TFA:
> That looks complicated, but remember how we built it: we looked at the hints and selected one option at a time. Now, if this is a log type we’ll use often, we are going to start to be able to write out that incantation without even looking at the hints. It’s both discoverable and efficient.
akagr 13 hours ago [-]
The important part is you don’t have to remember that gobbledygook. I don’t know why author posted that key stroke list as it seems to remove value from this post and make it look harder than it is.
Magit surfaces all available commands and options for you, along with key shortcuts as well as the actual git cli counterparts if you want to learn the raw command, too.
txru 14 hours ago [-]
These are indicated through context menus throughout specifying what the responses should be. It's a minimal UI though, and where `git rebase` is confusing magit rebase is confusing.
onfir3 13 hours ago [-]
Exactly my thought
sandinmyjoints 15 hours ago [-]
Rebasing in magit is so choice. I especially love magit-rebase-subset.
Especially for rebasing, subset rebases (using --onto, see https://git-scm.com/book/en/v2/Git-Branching-Rebasing#_more_...) are a breeze with Magit. I can't remember the order of branches to use on the CLI, in Magit it's just "r s" basically. It's really magic.
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.
So yeah, it's sad that people don't use Git to its full potential because almost no other Git interface works as well, and most people aren't going to learn Emacs just for a Git UI.
Not even close. Claude and codex are the best git gui.
Only exception is resolving conflicts.
The most important point for every gut IDE integration to me is that it cleanly maps to the file system and CLI state.
The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available.
OT but i've learned the hard way not to push people into emacs.
a few years ago i made the very stupid mistake of pushing some colleague to trying/learning emacs and then i found myself having to explain the same person everything as well as fix his elisp code from his ~/.emacs .
Reality is, i didn't want to have that role and that colleague wasn't interested in gnu emacs in the first place.
That was a very stupid mistake on my side.
Nowadays i just say things like "yeah it's magit, an emacs plugin" or "ah yeah, it's nice because you spend some time learning it and then you can bring it over from company to company, no licenses involved or other annoyances".
Some people are intrigued, most other absolutely aren't... And it's fine.
And I'm saying this as someone who has exclusively programmed in Emacs with Magit for the last 5 years in my job.
What makes you say that?
> what do you mean "save is C-x C-s?" what does that even mean?
Magit never asks you to C-x C-s save anything. Magit has its own independent set of discoverable keybinds.
Only in the past years have I started customizing it
My attraction to Emacs is stability and I can use it in text or GUI mode.
Many editors have come and gone in that time, many employers insist I use this or that piece of over designed, under done GUI. When I have the chance, back to Emacs
But it isn't graphical :-P.
Personally i've been often looking for an opensource Git GUI front end but couldn't find anything i'd like. My points of reference of decent tools -ignoring the underlying tech- are Perforce and TortoiseSVN under Windows and Fuel[0] (for Fossil) and KDESVN under Linux.
Perforce and Fuel are the two i like the most, followed by KDESVN and Tortoise. But since i'm on Linux and i stick with opensource projects, Perforce and Tortoise are out, leaving me with Fuel and KDESVN. I'm using KDESVN for a few projects where i don't care about external collaboration and want to store many binary files (which Subversion does it better that Git IMO), though KDESVN is very primitive and limited in what it supports (it doesn't support shelving at all, for example - in fact for anything beyond commit and checking the history you probably need to use the cli tool). I do not use Fossil much nowadays but i used it a lot in the past so i have a bunch of repositories in it, for which i use Fuel. Fuel is unfortunately not being developed anymore, though since it is opensource it doesn't matter much (which is a reason why i ignore anything non-opensource, i know there are some decent proprietary Git clients but for me they might as well not exist).
I think at some point i'll grab libgit2 and make something using Lazarus, probably something similar to Fuel. Unlike libsvn, which seems to be made in hell, libgit2 seems very sane and shouldn't be terribly hard to make something usable out of it.
In the meanwhile i use a combination of git cola, gitgui and gitk though they all feel like a hodgepodge of barely thought random features thrown in together (and i hate that they all want to impose their own idea of how i should format a message -especially git cola- which of course aren't identical between of them and aren't even close how i'd like to format the messages myself).
https://fuel-scm.org/fossil/index
Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command.
This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving.
Magit is not even close to be on the same level.
Any insane operation you want at your fingertips.
In most IDEs I feel that Git integration is an awkward badly integrated afterthought. They are also very much tied to the whatever IDE offers them in terms of available shortcuts, layouts, controls etc. (this applies to Magit, too).
Some of my idiosyncratic usage I developed with GitUp doesn't even exist in most (all?) Git tools: https://news.ycombinator.com/item?id=47329489 (see my most common workflow)
So the software is mac-only, you haven't used a mac in over 20 years so you haven't used this software and yet... you claim it's better than magit?
i mean, it's very dishonest at best.
Not what he said. You misparsed.
But none of them that I've tried have ever come close to the workflow.
I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.
Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
So no, I haven't tried that one because it's Mac only, but I'm not really seeing from the screen recordings the kind of workflow that I find so powerful in Magit.
I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts.
My most common workflow besides staging anything is (to make sure history is clean):
- split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit) - move new commit up/down the branch (doesn't require interactive rebase in GitUp) - squash up/down
(undo/redo from time to time)
As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent
> Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".
The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2]
However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason.
[1] I only have this blog post to confirm https://www.howardism.org/Technical/Emacs/magit-squashing.ht...
[2] There's another downside to GitUp: it's very slow on repos with huge histories. Probably due to the git library it's using.
My primary reason for using it is reviewing and staging commits. The non-linear staging with line granularity (which also lets you revert changes at the same time) is so, so very good when you care about crafting commits.
Most people think it's "just another interface on top of git" — without several in-depth examples it's difficult to realize that it actually allows you to complete really complex tasks quickly. I've seen this superficial take many times.
The exception is maybe diffing, where I just use meld as the difftool.
With magit, the routine git tasks are very fast & flowing, git becomes highly discoverable, and complex tasks are made easy.
For example of things that are tedious on the CLI: magit makes it easy to make "--fixup" commits (since you can select the commit you intend to fix up). Or if you want to use something like git-absorb, that's also easy in magit.
Or magit makes it easy to stage/unstage line by line.
I would single out the following for Magit:
1. Single key strokes for actions and toggles 2. Discoverability through "slide-ins" (TFA also explains this)
For 2, this means I press "c" for commit, this opens a popup showing me the next keypresses and what they do. So I can build up muscle memory for commands I know that are fast due to 1, and I can discover options that might help me due to 2.
If I don't know what to do at all, there's Ctrl+c, Ctrl+c to discover "entry-points" for Magit shortcuts.
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:
Even with a very minimal set of packages, text insertion, etc. is slower, and opening Magit (when it hasn't been loaded yet) takes about a second due to slow package loading.Emacs is my favorite editor, full stop.
But every time I open Neovim or Sublime for quick tasks, it's always painfully apparent how much faster they are when I CMD+Tab back to Emacs.
I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.
I think the current solutions for running things in separate threads are only for external tools. I guess to do more, a kind of protocol would need to be invented, that tells a process exactly what parts of the copied global state it may change and when it finishes, only those parts will be merged back into the main process' global state.
Maybe I understood things wrong and things are different than I understood them to be. I am not an Emacs core developer. Just a user, who watched a few videos.
Tramp can be sped up a bit. I remember seeing some blog posts about it. I guess if you need to go via more than 1 hop, it can get slow though.
What is the problem with mono repos?
>> 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.
So the miniscule increase in start time is a non issue
Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.
As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of.
It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)
But I typically start emacs at boot, and then it runs until I reboot. I usually have one GUI frame, and one tui frame running in tmux so I can easily attach to my emacs session from a different computer. I have an emacsclient wrapper that opens stuff from the command line in my running emacs (and also mail wrappers, so clicking on a mail link in a browser opens a mail compositor in emacs).
I'm using eyebrowse with a bunch of own convenience features for workspaces in emacs - stuff like "when I switch to a buffer it'll switch to the workspace wher e that buffer is open unless I tell it I want it here". Combine that with some custom SSH entry points and especially on the notebook where I only have one screen it's way more comfortable to use than the OS window management for a terminal/ssh session messy like me.
There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.
I think all software (or at least, any text editor) regardless of interface type should launch instantly. But it's more unjustifiable with TUI programs.
Yeah, it feels a bit weird to not have some isolation.
Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default).
[^1]: https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and...
Anyway, you can start N emacs instances and they can all have individual buffer states.
Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.
Text insertion lag is something I haven't experienced since 2019. Config issue?
project-find-file might be slow because of low gc-cons-threshold. I know consult gets around this by temporarily raising the threshold. These days, you can use the feature/igc branch to make these operations faster (although they are pretty fast anyway).
If you think emacs lacks <fundamental feature X>, think again!
Can you elaborate on this? I tend to use emacs exclusively in the terminal, since I'm often using them on remote workstations. For remote workstations, I can (a) open files using TRAMP, (b) open a remote GUI with X11 forwarding over SSH, or (c) open a remote TUI. TRAMP doesn't always play nicely with LSP servers, and remote TUIs are much, much more responsive than X11 forwarding.
Locally, the performance of emacs depends far more on the packages I load than on the GUI vs TUI, so I'm interested in hearing what overhead there would be.
For me, TUI is a dealbreaker because:
- No mixed-pitch support: I use mixed-pitch fonts in org-mode buffers and in outline faces in prog-mode buffers. And fonts are just plain nicer on the GUI, and it's much better to look at.
- No SVG support: (I might be wrong about this) I have a custom modeline with SVG artifacts and the artifacts fail silently on the TUI
- Keybind conflicts: I am not used to accounting for the terminal's keybinds. Also, I use xfce4-terminal, which does not support the Hyper modifier (which I use extensively).
Maybe, but I'd like to hear why you think this is such an antifeature for a single-threaded application.
Given the extra resources available these days, for example, why not just bring up a stand-alone ERC instance for chatting, if shared state is a concern?
For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect.
Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!
I agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]).
I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down.
[^0]: https://wiki.archlinux.org/title/Systemd/User#Automatic_star...
On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX?
vim still is a lot faster though.> vim still is a lot faster though.
you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all.
maybe try with a non-gui version of emacs (or maybe calling emacs -nw)
Tried it anyways, looks the same:
Altough I'm not using Emacs.app.
Not for the parts of it I use.
Like what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.
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 very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.
I finally gave it a try when I came across the majutsu package, which is a magit-like interface for jujutsu. I recommend it for Emacs/magit users wanting to try `jj`!
If that's the case, it also seems like you can do jj duplicate and repeat -o if you just want to create a branch to temporarily test against another branch and main.
A couple of things I tend to notice:
- In magit, I can run a raw git shell commands by pressing `:`; majutsu doesn't seem to have that, so I use Emacs ordinary `M-!`
- The default view in majutsu (log) isn't as slick as magit's. With magit, I'll routinely open it up to look at the repo status, browse through the diffs (expanding/collapsing), staging/unstaging, etc. With majutsu, most of that requires first opening up the log, then opening up the diff of a commit.
- Staging/unstaging in magit is quite nice. The analogous workflow in jj seems to be splitting/squashing, but that feels clunkier in majutsu.
I've not opened bugs or PRs for these things, since it's mostly vibes and I don't have actual solutions to offer ;-)
EDIT: Oh, I also remembered that `jj` ignores $PAGER and uses its own built-in paging by default. That tries to act like `less`, and doesn't work well in Emacs. It can't use env vars either, unless we set its pager to something like `sh -c "$PAGER"` (see https://docs.jj-vcs.dev/latest/config/#pager ). Since my $PAGER is always `cat`, I've just set that as jj's pager directly too.
The best part - it's a TUI program that's usable independently, that also happens to embed really well within vim.
The Emacs interface in general isn't massively like Lotus 1-2-3's, but magit's somewhat is. The above post goes into a bunch of detail, but what I remember most about my time using 1-2-3 (a long time ago now) was that the shortcuts were super easy to get accustomed to, because there was a prompt of some kind every step of the way. magit's rather similar prompts work well in this respect too. (Though you do still have to know how to use git. This is git, after all.)
Where there might be some more general overlap with Emacs: an apparent goal of Lotus 1-2-3 was, like Emacs, that its users would be able to automate it, and without too much bother given their knowledge of how to operate it in general. It's actually better than Emacs in this respect, because the macros seemed to be largely based on the keys you press; Emacs, by contrast, makes you jump through some hoops to figure out what the corresponding elisp for some sequence of keys might be. (The hoops are not hard to jump through! But they are there.)
(Along similar lines: Autodesk's Maya. And, to an extent, 3D Studio Max - though the scriptability there felt merely comprehensive, rather than pervasive. MaxScript was measurably less horrid than MEL though.)
This lets you add a single-line change to a commit way back somewhere in the log.
https://github.com/nvim-orgmode/orgmode
I use magit with a very large repository (100k files, millions of commits) it's still not lightning fast like it is with smaller repositories, I'm still finding it an improvement over the CLI.
My config notes this saves me ~13 seconds in git-status
[1]: https://docs.magit.vc/devel/magit/Performance.htmlAs a sibling said, you can disable much of that.
Over the years I opted to substitute most tools with simpler, UI-based ones (like LogSeq for org-mode) but I never found a good substitution for Magit.
Having a whole spacemacs setup just for one tool is a bit overkill though, so I just use basic git and accept having to deal with interactive rebases manually.
I would encourage anyone who relies on magit to sponsor tarsius to make his fantastic work sustainable.
A patch is an idea, not some snapshot of time. git allows for ideas manipulation. The rebase operation is adjusting ideas to fit a context. And with the reflog (which tracks every operations), you have undo for ideas manipulation.
"It's super easy! Just do l-Akqr␍=u2025-06-01␍-s--tests␍b!"
> That looks complicated, but remember how we built it: we looked at the hints and selected one option at a time. Now, if this is a log type we’ll use often, we are going to start to be able to write out that incantation without even looking at the hints. It’s both discoverable and efficient.
Magit surfaces all available commands and options for you, along with key shortcuts as well as the actual git cli counterparts if you want to learn the raw command, too.