> 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):
kill $(xdotool getwindowpid $(xdotool getmouselocation | cut -d : -f 5))
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.
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.