But Magit is so good that I start emacs up just to use it as my Git interface if I can't get by just with the CLI.
Sadly there is no Vim plugin that is competitive. There is vimagit [1], but it's not on par.
It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To start an entire Emacs instance from scratch (no "daemon" trickery: a real full Emacs instance), eval'ing "kill emacs" (ok, a small program if any bu still) and exiting.
I don't know which editor, in this day and age, can start and exit in 81 ms (besides vim and nano)?
Launching my full setup takes 1.1s: thousands of lines of elisp configuration.
I'm running the native-comp branch since six months (?): compilation of Emacs itself is a bit of a pain but running it is very smooth.
That's on a 6 or 7 years old Core i7 6700K / 16 GB of RAM. Hardly a speed demon (besides the NVMe M.2 PCIe 3.0 x4 SSD).
Configuration, IIRC, has got a few "tricks" to prevent the usual culprits from slowing Emacs: something to do probably with font-locking on very long lines (?) when I open such a file etc.
But it's overall more than snappy. I use ivy/avy/swiper and burntsushi's rigpgrep integrated into Emacs. Everything is not just fast but really fast.
I cannot even imagine on a modern machine like some AMD 5900X or Apple M1...
I'm hoping that GCC emacs will resolve some of these issues. A better Elisp backend will do so much for Emacs and all of it's modes. I think one of Guilemacs goals was to have a better elisp interpreter but I'm not sure they will ever be able to keep up with all the development that has been happening on Emacs
Use case: open a yaml file with syntax highlightning, scroll it with the mouse. The latency should be as low as possible.
Opening a very large file?
Edit: I have found that if I don't reboot my Mac, the environment that a launcher emacs finds is sometimes off. Is it the same slow if you launch from a terminal versus the dock?
I'm using Doom with pretty much default settings. Perhaps there's something heavy there.
If the Cocoa port runs well, well that changes everything to me
I use the Vim plugin for IDEA and evil mode in Emacs. Even things like holding 'j' or 'k' to scroll lines is painful in Emacs compared to IDEA.
I'll admit that if I spend some hours/days in Emacs, I stop noticing it much, so it isn't THAT egregious. But if I switch back and forth, it really sucks.
Emacs is at least an order of magnitude more responsive than IDEA (or any other JetBrains IDE). Start with a stock Emacs, no extra third party packages loaded, to get a sense of performance. There is a lot of great Emacs Lisp code out there, but the opposite is also true: Horrible code written by folks new to Emacs and Emacs Lisp, that can slow down Emacs a lot and contribute to a degraded experience. Which is why I recommend starting from scratch and incrementally adding third party code/configuration (ideally, understanding the code as you go along and avoiding packages with lots of dependencies).
https://www.gnu.org/software/emacs/manual/html_node/emacs/In...
I know, for example, that a lot of people who have tried both report that Doom Emacs is much faster than Spacemacs. That implies to me that it's not evil mode. For my part (fairly vanilla Doom setup), I find holding j/k to scroll in Doom is snappier than IntelliJ, on the same computer.
But then, I've also heard people complain that it's just the opposite on Windows, where Doom emacs is apparently just really laggy.
That said, I agree that the "works for me" discussions aren't very fruitful, and I'm definitely not here to tell you which editor to use. More observing that, what with how... emacsy... emacs is, you're definitely not alone. It's entirely possible that the problem you had is both something specific to how you had things set up, and also absolutely not at all your fault.
Switched over to VSCode with as many extensions as I could find to get me close to my Emacs setup (including edamagit) and it, to my surprise, was actually very productive. I've been using VSCode now for 6 months and 15 year old me in the 90s is very mad at current me for selling out.
Also, dang I miss coding in TS instead of Go.
Basically even doing something mundane like C-n/C-p in a dart-mode buffer takes up a lot of memory (~800mb), which causes very high GC pressure and everything visibly stutters. Here is the `profiler-report` output just now:
https://paste.gnugen.ch/paste/5zED
But it's not helpful beyond pointing out that `line-move` when called from `next-line` for some reason is memory intensive.
you could maybe try the two lines here (set the megabyte count, the third number, to your own liking): https://emacs.stackexchange.com/questions/34342/is-there-any...
I use emacs as my main editor, but as with all software it's easy to accidentally create situations where it gets laggy, regardless of hardware. Two that I've hit over the past 10 years: (1) On Windows only, movement of point in buffers with non-ascii characters lagged when said characters were visible due to frequent gc pauses. Was fixed by making emacs wait longer to do gc, and only when idle. (2) A theme that styled text with a box around it (customize-face) made buffer redisplay laggy. Not sure why; just turned it off.
I am using emacs on a Mac, often with a 4K screen, and generally have no problems. I did have a scrolling lag issue a few months ago, but it was because of a bit of code that I had added to my modeline that was doing way too much work every time something changed in the buffer. The profiler pointed me right to it.
I would guess if you have something like FlyMake configured for on-the-fly syntax checking, you could also get a "laggy" feeling.
Just launching and using a vanilla emacs session feels quite snappy in my experience.
Even better when you can actually hop into conflicted files and use smerge and language-specific tooling (LSP) to do "real IDE" stuff.
From what I gather, mainline Emacs was adversely impacted by changes in Mojave. [2][3] The end result, for me, is that any gains in the native compilation are swamped by the macOS issues. I'm hoping that Mistuharu rebases his work on the native-comp Emacs soon, so that I can get the best of both.
[1] https://bitbucket.org/mituharu/emacs-mac/src/master/
[2] https://www.reddit.com/r/emacs/comments/faz1fm/seeing_a_flas...
[3] https://emacs.stackexchange.com/questions/59966/is-it-possib...
Yeah, otherwise you're not comparing apples to apples ;)
What’s your setup like? I’ve experienced some lagging from time to time—almost always because I turned on some package I didn’t need. My thirst for responsiveness has won out and now it’s nice and snappy.
I’m personally not running the native-comp branch, but I hear lots of people say it’s a game changer. Native-comp recently got merged to master, so when Emacs 28 ships it should be available to everyone!
I really want Edamagit to work. I'm still getting my feet wet with VSCode but Git integration is a bit of a pain.
[1] https://www.emacswiki.org/emacs/GuileEmacs
I think a full rewrite in any language would have likely brought about a better UI experience.
I've been considering trying to replicate magit in a tui. I'm not sure if I should go for a straight port (many people might find useful, eventually) or change lots of things to make it fit my workflow (might be more likely to "finish" if I optimized for me).
My dream git workflow is rebase-first, i.e. you have multiple WIP commits at any given time, and can send an unstaged hunk to any of them with the same level of complexity.
[1] https://savannah.nongnu.org/projects/quilt [2] https://stacked-git.github.io/
I prefer a model where you use a forge for collaboration, and don't rewrite shared history. However, you use rebase extensively locally.
Right now I use magit with fixup. It's just more keystrokes. I want to be able to highlight a change to the workdir, hit a key and select a local commit (right now it's highlight, hit the fixup shortcut, select the commit, open a rebase at the appropriate early commit, complete the rebase). I also want to be able to partially stage a newly created file (right now it's cut and paste part of it into a temp file)
I just discovered today that intellij has the concept of named changesets (i.e multiple staging areas, and you select 1+ to commit). I like it, but I don't think you can check them out and they don't work with external git commands. My temp commits would just be regular commits prefixes with "wip: "
You're right, but I think they are not limited to it. Stgit has a command to directly convert patches to commits. Quilt deals only with patches. So the patches will have to be applied to working tree before they can be committed.
> I want to be able to highlight a change to the workdir, hit a key and select a local commit
> I just discovered today that intellij has the concept of named changesets (i.e multiple staging areas, and you select 1+ to commit).
I am still learning stgit, but I think this is what stacked patches essentially achieve. The patches can effectively be used as multiple staging areas. You can design multiple commits simultaneously and commit them independently. Here is my novice assessment of that workflow: https://gitlab.com/-/snippets/2126398
> I also want to be able to partially stage a newly created file (right now it's cut and paste part of it into a temp file)
That sounds like interactive staging (`git add -p` or `git add -i`). You can do the same in magit, in the status window by selecting the diff lines you want to stage. I use evil-mode and use visual mode for that selection. Am I missing something about your requirement?
At least in magit, you get the error "new file ... depends on old contents" if you try to stage a hunk of a newly created file.
(i.e. echo "foo\nbar" > file, then stage only "bar")
wonder what kind of projects do you use