When running previous-line, C-p or <up> the cursor jumps up a line without any issues or lags. When running next-line, C-n or <down> the cursor properly jumps down a line, but with a significant lag. When I hold the down key I can't even see the point moving, it just appears somewhere below. I ran the Emacs profiler and it seems that the culprit is cl-position. What it works out to be is that previous-line literally just moves the cursor, while next-line runs a whole lot of functions.

Profiler output

What is the issue and how can it be fixed?

  • Are you using visual-line-mode? Do you have some very long lines?
    – Drew
    Nov 18, 2016 at 16:16
  • I do not use visual-line-mode and I do not have any long lines. Nov 18, 2016 at 17:08

4 Answers 4


I have found an answer to my question through narrowing down the naughty bit and googling. I have managed to reduce the lag 10 TIMES!!!! I mean....It is insane on how much computing power next-line was using to move a cursor down ?!?!

The fix:

Put this code into your init.el: (setq auto-window-vscroll nil)

The proof:

Lag reduced significantly

Now next-line does not trigger line-move-partial therefore reducing the lag. I do not remember setting up auto-window-vscroll to t. It wasn't anywhere in any of my .el files, I am not sure how it got set to t to begin with. So if anyone has an performance issues with the cursor movement, then the above fix will reduce the lag from about 50%-80% cpu time to 5% cpu time !!!

To quickly check if you are affected just run C-h v auto-window-vscroll. If it is set to t you might be having major performance issues. Verify with the Emacs profiler if the cursor movement does indeed cause a lag.

Best of luck fellow Emacs lovers!!!

Source of fix

  • Please consider filing an Emacs bug (or enhancement request) for this: M-x report-emacs-bug.
    – Drew
    Nov 18, 2016 at 18:43
  • 2
    Will do, as I can see this being a problem for a lot of people. Nov 18, 2016 at 23:36
  • 1
    Thanks, Damian, it improves the performance but I still feel a bit unresponsiveness Apr 5, 2018 at 18:15

I'm not absolutely sure what is the problem, but your profiler report seems to indicate that posn-at-point performs more redisplay than expected, which in turns causes recomputation of the mode-line, and that powerline should make more effort to memoize its computation for the modeline.

IOW, I suggest you M-x report-emacs-bug and you might also report a bug to the powerline maintainers.


I noticed that my doom-modeline is also contributing to the lag. In fact, it is said in the doc of doom-modeline:

 ;; If it brings the sluggish issue, disable `doom-modeline-enable-word-count' or
 ;; remove the modes from `doom-modeline-continuous-word-count-modes'.

After setting (setq doom-modeline-enable-word-count nil) I got a noticeable speed-up in cursor movements.


It looks like you're using powerline. In particular, you're display the projectile project name in your modeline. There have been some improvements to the projectile package recently that have mitigated some of that. Make sure you're up to date.



It's also possible to memoize functions that the modeline calls. I've done this a lot on my modeline to make it very fast.

  • The problem has already been solved, Projectile or Power line were not the problem Mar 2, 2018 at 14:15
  • I'm glad you got it sorted. Your profile did point to the slowdown coming from projectile. It could be that setting auto-window-vscroll to nil just causes emacs to skip unnecessary mode-line calculations. Any way, glad you got it sorted! Mar 3, 2018 at 17:08
  • That is a good point. I really didn't have the time to check which package was the problem. Thanks for the suggestions though! Mar 3, 2018 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.