10 ms·

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

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 https://github.com/jreybert/vimagit

unhammer 5y ago
Tried native-comp? https://news.ycombinator.com/item?id=24117853 https://news.ycombinator.com/item?id=24117853
- dhess 5y ago
  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/ https://bitbucket.org/mituharu/emacs-mac/src/master/ [2] https://www.reddit.com/r/emacs/comments/faz1fm/seeing_a_flashing_screen_every_once_in_a_while_on/ https://www.reddit.com/r/emacs/comments/faz1fm/seeing_a_flas... [3] https://emacs.stackexchange.com/questions/59966/is-it-possible-to-prevent-screen-flashing-on-combination-of-isearch-and-recen https://emacs.stackexchange.com/questions/59966/is-it-possib...
  - AlexCoventry 5y ago
    Emacs 28 is much faster for me, on ubuntu, FWIW.
    - michaelcampbell 5y ago
      Where are you getting 28? https://mirrors.ocf.berkeley.edu/gnu/emacs/ https://mirrors.ocf.berkeley.edu/gnu/emacs/ only shows up to 27.
      - nvarsj 5y ago
        28 is the current master of Emacs. So you have to compile from source.
  - unhammer 5y ago
    > hoping that Mistuharu rebases his work on the native-comp Yeah, otherwise you're not comparing apples to apples ;)
ashton314 5y ago
> 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!
Steltek 5y ago
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.
iudqnolq 5y ago
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.
- deleted 5y ago
  [deleted]
- sreevisakh 5y ago
  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 https://savannah.nongnu.org/projects/quilt [2] https://stacked-git.github.io/ https://stacked-git.github.io/
  - iudqnolq 5y ago
    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 5y ago
      > 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 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?
TacticalCoder 5y ago
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...
- Tehchops 5y ago
  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 5y ago
    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
agumonkey 5y ago
> Emacs is too laggy for me as my main editor. wonder what kind of projects do you use
xvilka 5y ago
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 https://www.emacswiki.org/emacs/GuileEmacs [2] https://www.cliki.net/cl-emacs https://www.cliki.net/cl-emacs [3] https://github.com/robert-strandh/Second-Climacs https://github.com/robert-strandh/Second-Climacs
- ragnese 5y ago
  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.
ragnese 5y ago
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.
rjzzleep 5y ago
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/ https://jonas.github.io/tig/
MobileVet 5y ago
Have you tried Spacemacs w/ VIM bindings (evil mode)?
iib 5y ago
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.
lawn 5y ago
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 5y ago
  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 https://news.ycombinator.com/item?id=26736006. Maybe some of it will work for your case.
karl42 5y ago
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 https://github.com/tpope/vim-fugitive
cloverr20 5y ago
You could give tig a try, for anything git related i use that, its an tui with vim like mappings, and very customizable

unhammer 5y ago

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

dhess 5y ago
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/ https://bitbucket.org/mituharu/emacs-mac/src/master/ [2] https://www.reddit.com/r/emacs/comments/faz1fm/seeing_a_flashing_screen_every_once_in_a_while_on/ https://www.reddit.com/r/emacs/comments/faz1fm/seeing_a_flas... [3] https://emacs.stackexchange.com/questions/59966/is-it-possible-to-prevent-screen-flashing-on-combination-of-isearch-and-recen https://emacs.stackexchange.com/questions/59966/is-it-possib...
- AlexCoventry 5y ago
  Emacs 28 is much faster for me, on ubuntu, FWIW.
  - michaelcampbell 5y ago
    Where are you getting 28? https://mirrors.ocf.berkeley.edu/gnu/emacs/ https://mirrors.ocf.berkeley.edu/gnu/emacs/ only shows up to 27.
    - nvarsj 5y ago
      28 is the current master of Emacs. So you have to compile from source.
- unhammer 5y ago
  > hoping that Mistuharu rebases his work on the native-comp Yeah, otherwise you're not comparing apples to apples ;)

ashton314 5y ago

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

Steltek 5y ago

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.

iudqnolq 5y ago

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.

deleted 5y ago
[deleted]
sreevisakh 5y ago
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 https://savannah.nongnu.org/projects/quilt [2] https://stacked-git.github.io/ https://stacked-git.github.io/
- iudqnolq 5y ago
  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 5y ago
    > 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 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?

TacticalCoder 5y ago

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

Tehchops 5y ago
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 5y ago
  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

agumonkey 5y ago

> Emacs is too laggy for me as my main editor. wonder what kind of projects do you use

xvilka 5y ago

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 https://www.emacswiki.org/emacs/GuileEmacs [2] https://www.cliki.net/cl-emacs https://www.cliki.net/cl-emacs [3] https://github.com/robert-strandh/Second-Climacs https://github.com/robert-strandh/Second-Climacs

ragnese 5y ago
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.

ragnese 5y ago

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.

rjzzleep 5y ago

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/ https://jonas.github.io/tig/

MobileVet 5y ago

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

iib 5y ago

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.

lawn 5y ago

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 5y ago
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 https://news.ycombinator.com/item?id=26736006. Maybe some of it will work for your case.

karl42 5y ago

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 https://github.com/tpope/vim-fugitive

cloverr20 5y ago

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