[the_duke]

Emacs is too laggy for me as my main editor.

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.

[1] https://github.com/jreybert/vimagit

[TacticalCoder]

I upvoted you but... How comes Emacs is laggy for you? I'm running a beefy Emacs setup and it is really responsive. If anything Emacs in the nineties was "Eight Megabytes And Constantly Swapping" but... We're in 2021 now and now it's still 8 MB, so it's a rounding error (I'm only exaggerating a bit).

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

[mtalantikite]

I was a longtime Emacs user (and vim before that) and recently a project I was working on was far too laggy for me to actually work productively on in Emacs. It was largely due to me using various LSPs within Emacs -- the frontend was in TypeScript and the backend in Go, and inevitably things would grind to a halt on a 5 year old i7 MBP with 16GB of RAM.

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.

[da39a3ee]

I have the exact same story. Multiple LSPs in emacs was too hard to manage and seeing as some of it was typescript, much worse than the VSCode experience. Edamagit has made a very good start at emulating magit in VSCode. Still use emacs for magit though.

[the-smug-one]

It's probably too late for you :), but I use native-comp Emacs and it's blazing fast. At least lsp-mode+gopls is. I haven't gotten the chance to use this setup with Typescript's LS, but I've used gopls+clangd without slow downs.

Also, dang I miss coding in TS instead of Go.

[natrys]

I have the same experience. Being on master and nativecomp probably helps, and I also think eglot is tad smoother than lsp-mode. I am using 10 year old laptop, no friction at all with tsserver, elixir-ls or gopls. However I think the server itself is the biggest difference maker, because all hell breaks lose when I try dart/flutter even in a simple project. But to be fair, my neovim setup struggles with that too (nvim-lspconfig + nvim-compe).

[amake]

I use Dart/Flutter LSP (lsp-dart) in Emacs all the time very successfully. “All hell breaks loose” sounds like maybe you have a project cloned or created but not yet `flutter pub get`’d, in which case I have seen it act like practically every token is an error.

[wiredfool]

LSPs and Large JSX file highlighting seem slow to me.

[throwawayboise]

Emacs is still (AFAIK) entirely single-threaded. If you are performing some operation that blocks (e.g. a network call, a shell command such as "git clone") all other windows are blocked until that completes.

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.

[d0mine]

you don't need multiple threads to run things concurrently (such as network I/O, communicating with subprocesses) e.g., I believe url-retrieve in emacs doesn't stop the world (because there is -synchroniously version too). async is a thing

[unhammer]

magit runs git clone and such asynchronously. There's usable concurrency support in Emacs for things like network calls and external processes even though UI and pure elisp stuff is still single-threaded

[ragnese]

I know that these "works for me" discussion are often not fruitful. But, I'll ask this: have you done a several hour session of typing/programming into a JetBrains IDE? I'm claiming that on my work Macbook Pro, even just typing plain text into a file and scrolling lines in IDEA is smoother and more responsive than doing the same in Emacs.

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.

[metroholografix]

Something is definitely wrong with your configuration (in a wide sense, not necessarily restricted to just the editor).

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

[gpderetta]

Personally, I find that normally emacs latency is more than tolerable. But LSP is pretty bad, at least with clang-lsp, especially on a fairly loaded machine. I have yet to try the jit branch though.

[mumblemumble]

It's really hard to tell. The configurability of emacs is both a blessing and a curse. Since you can customize basically anything, there are all sorts of opportunities for funky config or a weird extension to slow things down.

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.

[creese]

If you're using HJKL to navigate more than a few lines, you're doing it wrong. Use 'search' instead.

https://www.gnu.org/software/emacs/manual/html_node/emacs/In...

[michaelcampbell]

Is it possible that your vi plugin is introducing some lag?

[jpeloquin]

> How comes Emacs is laggy for you?

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.

[darthrupert]

Perhaps this is about MacOS vs Linux. I'm also suffering from slow emacs on mac, and no combination of flags seems to help.

Use case: open a yaml file with syntax highlightning, scroll it with the mouse. The latency should be as low as possible.

[nvarsj]

It's most likely a Mac thing. And is probably the main reason I gave up on OS X as a serious work OS, since I'm so dependent on Emacs (org-mode in particular). I hope it gets sorted one day. Apparently it has to do with certain system calls on OS X just being very slow.

[dpbriggs]

Emacs on MacOS was also laggy for me before I started using the native comp feature. It takes a while to compile but it's seriously one of the best QoL changes I've had in years.

[pcr910303]

Does Emacs native-comp work outside X (i.e. works with the Cocoa port)? I thought it only worked through XQuartz b.c. gcc can’t parse the Objective-C required for the Cocoa port…

If the Cocoa port runs well, well that changes everything to me

[rurban]

Yes, it does. I run my macOS nativecomp Emacs on it. Just the UI is not as good as on X. I have my mouse miles more than on X.

[ryukafalz]

This is my experience as well. I know it can be fast because emacs absolutely screams on my Linux machines, but it's super sluggish on the Mac I have to use for work.

[taeric]

Fwiw, I'm not seeing lag on my end doing the same. Can turn on magit blame and it still scrolls fine. :(

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?

[darthrupert]

No, not very large.

I'm using Doom with pretty much default settings. Perhaps there's something heavy there.

[taeric]

I don't think anyone really wants to profile their editor. That said, if you have the cycles to spare, M-x profiler-start, scroll, M-x profiler-stop may have some obvious culprit.

[chalst]

I have a very underpowered Macos machine (2010 Mac mini) which faces latency problems with most things. Except Emacs. E.g., Eshell is much snappier for issuing shell commands than bash on iTerm2.

[jonnycomputer]

I don't find emacs especially laggy on mac os.

[Tehchops]

I'm using the Emacs Mac port on a modern(2019-era) MBP and it absolutely crawls when working on a large, multi-file Terraform code base.

[Decabytes]

Same. I have to work with large separated value files and it can get Emacs chugging on my Mac Book. Also any file large file that has any sort of highlighting (I.E a large xml file) can be difficult to work with.

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

[Tehchops]

Yea, it's quite unfortunate. Magit and Org-mode are killer, and don't really have 1:1 equivalents anywhere else.

[tngranados]

I think it's a Mac and an HDPI thing. I had to stop using emacs because it was too slow on my work MacBook Pro connected to a 4K screen. Scrolling was painful and only marginally better with nativecomp.

[b3morales]

If you are interested in continuing to use emacs, I'd suggest using the profiler to investigate. There's a good demo/depiction of doing that here: https://www.murilopereira.com/how-to-open-a-file-in-emacs/ (posted recently to HN). I think it's most likely to be something pretty specific/small in the config you're using.

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.

[tngranados]

Will take a look, thanks!

[weavie]

I've recently had to dump Emacs for Vim. I found with using Rust Analyzer on Emacs, it would regularly lock up for a number of seconds. With Vim (NeoVim anyway) this does not occur.

[spamizbad]

Likely an OSX user. Emacs on my 2018 MBP is noticeably slower than my 2016 Dell XPS running Linux - despite the MBP having more ram, more clocks, and more cores.

[ragnese]

Yeah. I still use Emacs for actual development sometimes, but it's been less and less, honestly. But it isn't going anywhere as my git porcelain. I used to scoff at even the concept of a git porcelain- I never used my IDEs' tools to do git ops because I thought they were weird, leaky abstractions, and that you just have to learn "real" git anyway. But Magit doesn't hide git from you- it's just a really nice, interactive, interface over git.

Even better when you can actually hop into conflicted files and use smerge and language-specific tooling (LSP) to do "real IDE" stuff.

[unhammer]

Tried native-comp? https://news.ycombinator.com/item?id=24117853

[dhess]

I have, on macOS, and somehow, it has much much worse lag than Mitsuharu Yamamoto's Emacs "Mac port," [1] which is still based on Emacs 27.2. The native comp version was so slow that I gave up and switched back to Mitsuharu's port, which is snappy enough for my needs even without the native compilation bits.

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

[AlexCoventry]

Emacs 28 is much faster for me, on ubuntu, FWIW.

[michaelcampbell]

Where are you getting 28? https://mirrors.ocf.berkeley.edu/gnu/emacs/ only shows up to 27.

[nvarsj]

28 is the current master of Emacs. So you have to compile from source.

[unhammer]

> hoping that Mistuharu rebases his work on the native-comp

Yeah, otherwise you're not comparing apples to apples ;)

[ashton314]

> Too laggy

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!

[karl42]

I'm really happy with fugitive[1] for vim. Can anyone compare those two well enough, so that I understand what I am missing?

[1]: https://github.com/tpope/vim-fugitive

[Steltek]

Likewise with VSCode, Edamagit is very close but isn't "muscle memory" close. I run into things that aren't quite the same as the original: choosing a remote on a new repository when pushing or selecting switches using the VSCode native pop-up.

I really want Edamagit to work. I'm still getting my feet wet with VSCode but Git integration is a bit of a pain.

[xvilka]

They could have solved this with porting from single-threaded Emacs Lisp to Guile[1] or a proper Common Lisp[2]. Sadly, both initiatives didn't get enough steam. Someone, though, started to rewrite Climacs in SBCL from scratch[3].

[1] https://www.emacswiki.org/emacs/GuileEmacs

[2] https://www.cliki.net/cl-emacs

[3] https://github.com/robert-strandh/Second-Climacs

[ragnese]

I'm not convinced that Elisp-the-language is really the limiting factor. I'm not an expert on the details- just a passive observer for several years. But, IIRC, Elisp recently got some kind of cooperative async stuff. Even before that, my understanding was that there are a lot of legacy architecture issues with Emacs, from its GUI model to the actual text data structures, that contribute to to latency/slowness.

I think a full rewrite in any language would have likely brought about a better UI experience.

[iib]

Can you try `lsp-doctor` and try to resolve any performance hints it outputs? The latest `lsp-doctor` seems to also know about the native compiler, so one less thing to worry about when checking.

[iudqnolq]

I agree.

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.

[sreevisakh]

Interesting! Is that workflow similar to what Quilt [1] or Stacked Git [2] is used for? And how do you achieve that now?

[1] https://savannah.nongnu.org/projects/quilt [2] https://stacked-git.github.io/

[iudqnolq]

Those look interesting. If I understand them right they've for mailinglist-based dev where you email patches around?

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: "

[sreevisakh]

> If I understand them right they've for mailinglist-based dev where you email patches around?

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?

[iudqnolq]

> 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")

[rjzzleep]

I find magit cool, but I always find myself going back to using tig or !tig (combined with git add -p for interactive adding) inside of vim. It's a lot faster of all the editor extensions for me.

[1] https://jonas.github.io/tig/

[MobileVet]

Have you tried Spacemacs w/ VIM bindings (evil mode)?

[lawn]

I agree. At work we use Windows and all the dev tools are integrated to Emacs (and Emacs alone). And magit is just incredibly slow.

[TeMPOraL]

I had some performance issues with Magit (and git in general) under Windows, but ultimately resolved them. I documented the solutions here: https://news.ycombinator.com/item?id=26736006. Maybe some of it will work for your case.

[cloverr20]

You could give tig a try, for anything git related i use that, its an tui with vim like mappings, and very customizable

[agumonkey]

> Emacs is too laggy for me as my main editor.

wonder what kind of projects do you use