> been using emacs for several years... What could be improved is speed.
Same here. Long lines are especially painful. And it's quite surprising what Emacs considers a "long line". I have a file in my project with tests, where I have an array, with each element of the array on a separate line, averaging at around 125 characters per line (some of them weird Unicode characters, so not just ASCII). There are 52 lines of it. And when I scroll down the file with C-v (Page Down basically) it scrolls quickly up until I get close to this place, then I get something like 1.5 seconds delay while it's hanging there. It's ridiculous.
Another thing is how easy it is to freeze Emacs into being completely unusable when editing files over Tramp (with remote work it's the go-to solution), caused by an unreliable connection. Mostly it happens when the underlying VPN connection is dropped. When that happens, Emacs freezes with no explanation whatsoever. I can only guess what happened. C-g, Esc, nothing works, regardless whether the VPN connection is restored or not. The only solution at this point is killing this instance of Emacs. Specifically for this purpose I crafted a one-liner to kill the right instance of Emacs[1] (the one under the mouse pointer):
Also, magit is painfully slow. When using it, I always wonder if Emacs is frozen again, or if it's just magit being magit. It's a shame Fork is not available for Linux.
[1]: The other instance of Emacs is used for tracking in org-mode the time I spend on different tasks. I used to do it all in a single instance, but then I kept losing that data due to Emacs freezing like that, so I started using a separate instance for the time-tracking. I really think Emacs should be a multi-process application to prevent such situations.
Regarding your long lines issue - from your description it sounds instead like an unicode issue which I also ran into a while back.
What happens is that your main programming font does not have the unicode characters, so Emacs falls back to searching all your fonts for each character it can't find, which is slow if it has to search through many different fonts.
> some of them weird Unicode characters, so not just ASCII
This makes me suspicious that it's the font cache causing the slowdown (assuming Windows), not long lines. I saw similar symptoms a couple years ago and fixed it with (setq inhibit-compacting-font-caches t).
You could also try increasing the garbage collection threshold on the theory that the lag is a gc pause. I've used:
Magit performance issues are definitely disappointing and I definitely wish it had a better out of the box experience. However there are plenty of resources on how to improve its performance. It's really only on big monorepos where it's frustratingly slow after mitigations. But again I agree it should have a better out of the box experience and I'm sure the maintainers agree.
Same here. Long lines are especially painful. And it's quite surprising what Emacs considers a "long line". I have a file in my project with tests, where I have an array, with each element of the array on a separate line, averaging at around 125 characters per line (some of them weird Unicode characters, so not just ASCII). There are 52 lines of it. And when I scroll down the file with C-v (Page Down basically) it scrolls quickly up until I get close to this place, then I get something like 1.5 seconds delay while it's hanging there. It's ridiculous.
Another thing is how easy it is to freeze Emacs into being completely unusable when editing files over Tramp (with remote work it's the go-to solution), caused by an unreliable connection. Mostly it happens when the underlying VPN connection is dropped. When that happens, Emacs freezes with no explanation whatsoever. I can only guess what happened. C-g, Esc, nothing works, regardless whether the VPN connection is restored or not. The only solution at this point is killing this instance of Emacs. Specifically for this purpose I crafted a one-liner to kill the right instance of Emacs[1] (the one under the mouse pointer):
Also, magit is painfully slow. When using it, I always wonder if Emacs is frozen again, or if it's just magit being magit. It's a shame Fork is not available for Linux.[1]: The other instance of Emacs is used for tracking in org-mode the time I spend on different tasks. I used to do it all in a single instance, but then I kept losing that data due to Emacs freezing like that, so I started using a separate instance for the time-tracking. I really think Emacs should be a multi-process application to prevent such situations.