4 ms·

i used emacs and magit for 8 years before switching to neovim a few months ago. i’ve switched between the two for a while, but the truth is that emacs is just s

i used emacs and magit for 8 years before switching to neovim a few months ago. i’ve switched between the two for a while, but the truth is that emacs is just so much slower than vim, and hangs so often for my usecase (a large go project using eglot and gopls). since i had switched to evil a few years back, going to nvim+lazygit wasn’t a big change and now i don’t have to wait for emacs to block for seconds at a time.

Icathian 4y ago
I'm working on a pretty huge go project with lsp and a ton of bells and whistles and haven't had it noticeably lag on anything. Out of curiosity how big were the files/projects in your case? Did you have some other super heavyweight modes going?
- yakubin 4y ago
  Not the commenter you're replying to, but I've also struggled with Emacs freezing whenever I used Magit. See <https://news.ycombinator.com/item?id=34946051 https://news.ycombinator.com/item?id=34946051>.
deleted 4y ago
[deleted]
zelphirkalt 4y ago
I have only noticed magit, or rather Emacs itself, to hang, when the diff contains binary files and very long lines. Magit then tries to create a proper diff buffer showing the diff of those very long lines and chokes. I think there has been some improvement in modern Emacs versions for handling long lines, but things can still get slugish when a whole binary file is a single line. Often people put things in the git tree, that should not be there. Maybe there is an option somewhere in magit to not show diff completely for files with specific file extension or something.
- yakubin 4y ago
  Steps to reproduce: 1. Clone <https://chromium.googlesource.com/chromium/src https://chromium.googlesource.com/chromium/src>. 2. Navigate to this directory in Emacs dired. 3. Run magit-status. 4. Observe how long it takes for Emacs to become responsive again. For me it's 28 seconds, while running git status in the terminal takes 6 seconds.
  - zelphirkalt 4y ago
    Hm. Fails at step 1: Cloning using git on command line hangs. -- wait, correction: It now did start to clone ... lol: $ git clone https://chromium.googlesource.com/chromium/src https://chromium.googlesource.com/chromium/src Cloning into 'src'... remote: Sending approximately 36.75 GiB ... So it is not at all surprising, that things get laggy, when you run them on 36.75 GiB. You probably do not want to check out everything at once.
    - yakubin 4y ago
      My issue is not that things are laggy in this case, but that they are 5 times as laggy as the command line interface. > You probably do not want to check out everything at once. I do, if I want to compile the project, browse its history and push commits, which is what I'm paid for.
      - zelphirkalt 4y ago
        Have you tried any GUI tool and found a less laggy one? Consider the extra work and data structure representation in the magit buffers in Emacs, that is not done on command line. For example magit makes diffs and chunks of diffs neatly foldable. It also colors things in that foldable content. It also has context knowledge, when you move your point over some diff or chunk and then run another command / Emacs procedure. It probably does some more things I cannot think of right now. Somewhere there is a cost associated with having more than a simple stream of text that is output exactly once, like on command line. Is it still 5 times as laggy, once the initial magit-status is calculated? Does it recalculate all the things, when you stage a chunk of a diff, or does it profit from having a data representation of the diff in memory?
pmoriarty 4y ago
I used vi/vim for 25 years before switching to emacs about 10 years ago, and I have not gone back to vim despite emacs occasionally hanging. The advantages that emacs offers over vim for me are just way too great to give up.

Icathian 4y ago

I'm working on a pretty huge go project with lsp and a ton of bells and whistles and haven't had it noticeably lag on anything. Out of curiosity how big were the files/projects in your case? Did you have some other super heavyweight modes going?

yakubin 4y ago
Not the commenter you're replying to, but I've also struggled with Emacs freezing whenever I used Magit. See <https://news.ycombinator.com/item?id=34946051 https://news.ycombinator.com/item?id=34946051>.

deleted 4y ago

[deleted]

zelphirkalt 4y ago

I have only noticed magit, or rather Emacs itself, to hang, when the diff contains binary files and very long lines. Magit then tries to create a proper diff buffer showing the diff of those very long lines and chokes. I think there has been some improvement in modern Emacs versions for handling long lines, but things can still get slugish when a whole binary file is a single line. Often people put things in the git tree, that should not be there. Maybe there is an option somewhere in magit to not show diff completely for files with specific file extension or something.

yakubin 4y ago
Steps to reproduce: 1. Clone <https://chromium.googlesource.com/chromium/src https://chromium.googlesource.com/chromium/src>. 2. Navigate to this directory in Emacs dired. 3. Run magit-status. 4. Observe how long it takes for Emacs to become responsive again. For me it's 28 seconds, while running git status in the terminal takes 6 seconds.
- zelphirkalt 4y ago
  Hm. Fails at step 1: Cloning using git on command line hangs. -- wait, correction: It now did start to clone ... lol: $ git clone https://chromium.googlesource.com/chromium/src https://chromium.googlesource.com/chromium/src Cloning into 'src'... remote: Sending approximately 36.75 GiB ... So it is not at all surprising, that things get laggy, when you run them on 36.75 GiB. You probably do not want to check out everything at once.
  - yakubin 4y ago
    My issue is not that things are laggy in this case, but that they are 5 times as laggy as the command line interface. > You probably do not want to check out everything at once. I do, if I want to compile the project, browse its history and push commits, which is what I'm paid for.
    - zelphirkalt 4y ago
      Have you tried any GUI tool and found a less laggy one? Consider the extra work and data structure representation in the magit buffers in Emacs, that is not done on command line. For example magit makes diffs and chunks of diffs neatly foldable. It also colors things in that foldable content. It also has context knowledge, when you move your point over some diff or chunk and then run another command / Emacs procedure. It probably does some more things I cannot think of right now. Somewhere there is a cost associated with having more than a simple stream of text that is output exactly once, like on command line. Is it still 5 times as laggy, once the initial magit-status is calculated? Does it recalculate all the things, when you stage a chunk of a diff, or does it profit from having a data representation of the diff in memory?

pmoriarty 4y ago

I used vi/vim for 25 years before switching to emacs about 10 years ago, and I have not gone back to vim despite emacs occasionally hanging. The advantages that emacs offers over vim for me are just way too great to give up.